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VIRTPALIZED MULTIMEDIA CON NECTION SYSTEM 
Background of the Invention 
The invention relates generally to multimedia 
connection systems . ^ 

With few exceptions, systems supporting facilities 
for the sharing of live audio and motion-video images 
have provided integrated hardware platforms that 
contained both video encoding/decoding devices and an 
Integrated Services Digital Network Basic Rate Interface 
(ISDN/BRI) . Stand-alone, dedicated video conferencing 
systems began as wholly proprietary designs (early video 
conferencing systems from PictureTel Corporation and 
Compression Laboratories, Inc.)/ but by 1993, 
conferencing products based on the personal computer 
became available. These systems relied upon standardized 
operating systems to host command, control, and user 
interface software components. Specialized hardware 
support for videoconferencing services was implemented in 
adapter board configurations that contained real-time 
video processing facilities, integrated with an ISDN/BRI 
hardware component (PictureTel SIOOO, CLI Eclipse) ; For 
all intents and purposes, the software architectures used 
in the implementation of the motion-video connectivity 
sub-systems have been extremely tenuous, and essentially 
unusable as discreet modular components in that they 
lacked a comprehensive, extensible software model to 
support the diversity of underlying hardware 
technologies • 

Perhaps the best attempt at creating a simple, 
reusable motion-video connectivity sub-system for 
integration into second-party products is available from 
Zydacron, Inc. (Zydacron Z240, Z250) . Even the simple, 
clean implementation of this system's software control 
mechanism requires many months of specialized software 
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development, including significant design and 
implementation of complicated protocol components, before 
the sub-system is usable in a commercial product • 

ITU-T RBCOHMENDATZON B.320 

5 Motion-video connectivity, between systems from 

different vendors, is possible only through the general 
acceptance of standardized protocols for interconnection 
between local and remote stations. in March of 1993, the 
International Telecommunication Union (ITU-T) adopted 

10 Recommendation H.221 (LINE TRANSMISSION OF NON-TELEPHONE 
SIGNALS) as the standard for the interconnection of 
devices supporting the exchange of audio, video, and 
binary data types (see ITU-T Recommendation H.221, FRAME 
STRUCTURE FOR A 64 TO 1920 kbits/ s CHANNEL IN AUDIOVISUAL 

15 TELESERVICES , 1994. This protocol is grouped with two 

other related interconnection protocols under the rubric 
of Recoxnmendation H.320, which is now the generally 
accepted set of protocols for implementing composite 
audio/motion-video/data connectivity across the 

20 Integrated Services Digital Network as embodied in 
narrow- band visual telephone systems ISDN- see, ITU-T 
Recommendation H.3 20, NARROW-BAND VISUAL TELEPHONE 
SYSTEMS AND TERMINAL EQUIPMENT, 1994). Recommendation 
H.320 is a virtualized definition of an extensible, 

25 finite set of capabilities, device modes, data transfer 
frame structures, and call control procedures. At some 
level in the software layers that comprise H.320- 
compliant connectivity stations, there must be (by 
definition) an implementation of a significant subset of 

30 the Recommendation H.320 multimedia interconnection 
services. Despite this distinct commonality shared by 
inter-connectable stations, there are no commercially 
available software models, known to this author, that 
promote these standardized audiovisual/data connectivity 
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services to a useful, consistent, reusable kernel of 
device-independent software control elements. 

SYSTEM ARCHITECTURES 

System and user interface software designs for, 
5 multimedia connectivity stations have typically been 
derived directly from the service profile of the 
xinderlying devices that they control — multimedia 
connectivity software architectures are mostly hardware 
driven. Since multimedia connectivity tasks, such as 
10 videoconferencing, require synchronous encoding/ decoding 
of audio and video data at high data rates emanating 
to/ from synchronous data transfer connectivity devices, 
most of the motion-video connectivity devices integrate 
all the necessary components onto one large, multi- 
is purpoise device. Typically these devices take the form of 
an ISA or EISA personal computer adapter that includes 
additional hardware support for specialized video overlay 
ftinctions. Without a major software development effort, 
it is impossible to utilize the manufacturer's sub-system 
20 for a new connectivity application. Those wishing to 

impart videoconferencing services to their enterprise are 
most frequently restricted to the single software 
application program provided by the hardware vendor; that 
is the only one capable of sufficiently driving the 
25 vendor's complicated hardware configurations. PictureTel 
Corporation, Zydacron, Inc., and Compression Labs, Inc., 
design and develop most of the world's motion-video 
connectivity sub-systems according to this multiple 
integrated device architecture. These systems perform 
30 well for stand-alone videoconferencing purposes. Recent 
attempts by Intel Corporation to produce software video 
solutions with minimal hardware support, are of inferior 
image and sound quality. The allocation of valuable 
central processing unit resources to real-time video 
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encoding/decoding tasks is inefficient at 128 kbit/s data 
transfer rates, and entirely inappropriate at transfer 
rates of 384 kbit/s, or more. A data transfer rate of 
384 kbit/s is required to produce motion-video connection 
services with frame rates and image clarity sufficient 
for large-scale acceptance of these technologies; a 128 
kbit/s data transfer rate produces video image quality 
that can best be described as "disappointing" to 
uninitiated technology customers who typically expect a 
broadcast quality television image (see D. Minoli and R. 
Keinath, Distributed Multimedia Through Broadband 
Communications Services, Norwood, Massachusetts, Artech 
House, pp. 187-207, 1994) • There will likely continue to 
be a continuous stream of hardware and software solutions 
to improve the quality of motion-video connectivity using 
personal computers, and systems will continue to undergo 
rapid change as high-bandwidth ISDN connections become 
cost effective and generally available. In consideration 
of the extraordinary engineering effort required to 
produce motion-video connectivity systems, and the 
difficulties of developing software to support new 
devices, more can be done to reuse the high-level 
applications and protocol support code developed for 
these products. 

Summary of the in vention 
VTRTUALXZED SYSTEM DESIGNS 

An analogous problem to that of the hardware- 
driven software designs in multimedia connection systems 
can be found in the early attempts to create Graphical 
User Interfaces for the wide variety of graphics hardware 
used with personal computers. Here again, hardware 
features influenced overlaying software designs, with a 
proprietary device driver interface supported by almost 
every distinct video graphics adapter manufacturer. The 
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Microsoft Windows Operating Erivironment, and the 
Operating System/ 2 Presentation Manager, solved the 
problems related to video graphics hardware variability 
by abstracting the services of these devices to a fully 
device-independent model. The original Microsoft solution 
is called the Graphics Device Interface (GDI) , and it is 
the paradigm shift in video graphics technology made 
possible by this particular product component, that has 
helped promote the Graphical User Interface (GUI) to its 
ubiquitous market position. The invention of the GDI 
allowed the development of GUI applications that would 
run over any graphics hardware integrated according to 
the GDI's prescribed methodology (see C. Petzold, 
Programming Windows 3.1, Redmond, Washington, Microsoft 
Press, Chapter 11, 1992. 

The principle that underlies the GDI is that there 
exists a finite set of graphical operations that will 
enable a software developer to draw just about anything 
on a bitmapped display device. It is taken into 
consideration that some graphics hardware is more or less 
suitable for the direct implementation of these 
operations; some operations may not be supported at all 
by the hardware. To derive a set of abstract, logical 
operations, without giving consideration to the 
underlying mechanism needed to support them, is referred 
to as the process of virtualization. In a GDI 
implementation, any graphics operation that may be 
supported directly by a hardware function, is accessed 
directly using a vendor-^specif ic device driver. If a 
close mapping of a physical to a logical graphical 
operation exists, some software modification of the 
physical operation, to better implement the desired 
logical operation, is invoked as needed. If no hardware 
support exists for the operation, it may be emulated 
entirely in software, or marked as a task of which the 
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vendor-specific driver is incapable. A structured 
capability report mechanism is available to applications 
using GDI, so that they may determine if a specific 
operation is even possible. Regardless of whether a 
5 particular operation is supported by the graphics device 
per se, or can be emulated, if there is any way GDI can 
fulfill the request for service, then the graphical 
system is considered to be capable. This same 
virtualization principle behind the Graphics Device 
10 Interface can be expanded to create a logical description 
of operations necessary to fully describe multimedia 
interconnection operations. 

A VlRTUAIilZBD X0X.TIHEDIA CONNECTIVITY SYSTEM 

Videoconferencing is but one interesting 
15 multimedia connectivity service. However, what is needed 
is a change in the way we view multimedia 
interconnection, not only in terms of the logical 
operations we wish to perform, but in a way that most 
advantageously applies those operations to specific 
20 configurations of audio-video transducers, and diverse 
sources of synchronous data connectivity. A generalized 
model for multimedia connectivity application development 
must take into consideration that the essence of these 
technologies is the structured sharing of sound and light 
25 spectral data (as opposed to binary data) . The vendor- 
specific facets of media transducers and network 
interfaces employed to implement related services must be 
rendered entirely irrelevant to the operation of software 
programs desirous of device-independent audiovisual 

30 teleservices. 

In that regard, an efficient, consistent, and 
extensible presentation of multimedia connectivity 
services to software programs is achieved through the 
appropriate run-time binding of media transducers to 
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connectivity protocol stacks. Device-independent 
multimedia connectivity services are abstracted, in 
software, to an externally consistent media and network 
interface control interface. A single binary software 
5 object is constructed to encapsulate all relevant 

hardware and software components necessary to support 
virtualized multimedia connection services . These 
services are accessed through manipulation of the 
object's members. A specific instance of the 
10 virtualized, encapsulated media control and connectivity 
components required to implement the defined services, is 
referred to as a Virtual Connection Object (VCO) . Each 
VCO contains a reusable Virtual Device Interface (VDI) 
software component that contains the VCO's Software 
15 Control Interface (SCI) and device- independent 

media/ connection device control methods. The VDI derives 
implementation of its services from a Virtualization 
Layer (VL) . The Physical Device Interface (PDI) provides 
control of the physical media transducers and one or more 
20 network interface units, in a fashion consistent with 

both the technicjues specified by their manufacturers, and 
in a way that enables their efficient utilization by 
methods in the VL. Device-generated events, occurring in 
real-time, asynchronous with the system scheduler, are 
25 ins CTtcd into an infinite event queue, to be periodically 
dispatched to the VDI, synchronous with the system 
scheduler. Physical limitations on the level of service 
provided by encapsulated media transducers /network 
interface, are expressed as the Local Capabilities. When 
30 connected, the capabilities of the remote station are 
expressed as the Remote Capabilities, and are available 
to the constructor of the VCO. The quality of the 
connection is described as the logical intersection of 
both the Local Capabilities and the Remote Capabilities, 
35 and is referred to as the Connection Capabilities. VCO 
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imp leiaentat ions abstract multimedia connectivity sezrvices 
to the level of the Open Systems Interconnection 
Reference Model Presentation Layer; device-dependent 
control methodologies for vendor*specif ic media 
5 transducers and connectivity protocol stacks have no 
representation in the Presentation Layer. Software 
programs that construct VCOs and utilize the presented 
multimedia connectivity services, are referred to as VCO 
Clients. These device* independent connectivity programs 

10 realize the benefits of interoperability across any 

multimedia connectivity sub-system that encapsulates its 
services into a Virtual Connection Object, according to 
the disclosed methodology. 

In general, in one aspect, the invention is a 

15 multimedia connectivity program residing in computer 

readable memory. The connectivity program when executed 
on a computer providing to an application program 
multimedia connectivity services through a real-time 
multimedia device control subsystem including components 

20 selected from among a plurality of multimedia devices and 
a plurality of real-time multimedia protocol stacks. The 
program includes a single binary object encapsulating a 
virtual device interface and a device control interface. 
The virtual device interface includes a plurality of 

25 virtual methods that represent logical operations 

available to the application program for controlling the 
multimedia device control subsystem. The plurality of 
virtual functions are completely independent of the 
components within the device control stibsystem. The 

30 device control interface mapps the plurality of virtual 
functions to physical control methods which control the 
components of the multimedia control subsystem. 

In preferred embodiments, the device control 
interface includes a plurality of media control objects 

35 which represent audiovisual and binary data streams 



wo 98/09213 



PCT/US97/15018 



- 9 - 

associated with the coiaponents of the plurality of 
devices and/or real-time multimedia protocol stacks. The 
virtual device interface is configured to present a 
logical representation of the multimedia connectivity 
5 services provided by the connectivity progreun. The 
device control interface includes a virtualization layer 
and a physical device interface layer, the virtualization 
layer being located between the virtual device interface 
and the physical device interface. The physical device 
10 interface directly interfaces to the device control 
subsystem to provide a physical implementation of 
services requested by the application through the virtual 
device interface. The virtualization layer resides 
between the virtual device interface and the physical 
15 device interface layer and is configured to translate and 
map device control mechanisms employed by the underlying 
inultimedia control sub-system to representations required 
by the virtual methods of the virtual device interface. 

Also, in preferred embodiments, the pl\irality of 
20 media control objects provides the multimedia 

connectivity control program with a pool of media device 
signal resources. Each of the plurality of media control 
objects is classified as at least one of type of the 
group consisting of an audio type, a video type, an image 
25 type-f-r^aftd^ a binary data type. Also, each of the 

plurality of media control objects represents a -signal 
from the group consisting of a signal from a remote 
station, a signal to a remote station, a signal from a 
local output device, and a signal to a local output 
30 device. The operations performed on the plurality of 

media control objects by the physical device layer under 
control of the virtual device interface implements a 
logical software switching mechanism. The virtual device 
interface implements a plurality of public member 
35 functions, the virtual functions being a subset of those 
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public member functions and the plurality of public 
member functions representing all of the public member 
functions in the single binary object that are accessible 
by the application program. 

In general, in anotehr aspect, the invention is a 
computer programmed to provide to an application program 
multimedia connectivity services through a real-time 
multimedia device control subsystem. The multimedia 
device control subsystem includescomponents selected from 
among a plurality of multimedia devices and a plurality 
of real-time multimedia protocol stacks. The prograauned 
computer includes a virtual device interface and a device 
control interface, both of which are encapsulated in a 
single binary object. The virtual device interface 
includes a plurality of virtual methods that represent 
logical operations available to the application program 
for controlling the multimedia device control subsystem. 
The plurality of virtual functions are completely 
independent of the components within the device control 
subsystem. The device control interface maps the 
plurality of virtual functions to physical control 
methods which control the components of the multimedia 
control subsystem. 

In general, in yet another aspect, the invention 
is a computer implemented method of providing multimedia 
connectivity services through a real-time multimedia 
device control subsystem. The multimedia device control 
subsystem includes components selected from among a 
plurality of multimedia devices and a plurality of real- 
time multimedia protocol stacks. The method includes the 
steps of defining and supporting by computer implemented 
steps a virtual device interface; and defining and 
supporting by computer implemented steps a device control 
interface. Both the virtual device interface and the 
device control interface are encapsulated in a single 
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binary object. The virtual device interface includes a 
plurality of virtual methods that represent logical 
operations available to the application progrcun for 
controlling the multimedia device control subsystem. The 
5 plurality of virtual functions are completely independent 
of the components within the device control subsystem. 
The device control interface maps the plurality of 
virtual functions to physical control methods which 
control the components of the multimedia control 

10 subsystem. 

Multimedia connectivity sub-systems, when 
developed for use in a VMCS, present an externally 
consistent, fully abstracted set of logical operations to 
software programs, therewith exposing the faculty to 

15 create adjunct, device- independent , interoperable 

multimedia connectivity software application programs. 
The disclosed invention is a methodology to enable the 
structured sharing of spectral information between 
interconnected microcomputer stations. Though 

20 principally intended to facilitate control of live audio 
and (motion) video information, this comprehensive 
connectivity paradigm incorporates mechanisms for store- 
forward operations; binary data object transfers are also 
supported. For the purposes of practical consideration, 

25 the VMCS pursues a classic client-server model of 
application/ sub-system interaction. The sub-system 
presents a coherent software control mechanism to device- 
independent connectivity applications created explicitly 
to utilize its structured, highly-typed, set of services. 

30 Insofar as software programs benefit from 

virtualized binary data sharing technologies, the same 
benefits may be realized by those sharing spectral 
information, if the system is implemented as a 
Virtualized Multimedia Connection System (VMCS) . 
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Other advantages and features will become apparent 
from the following description of the preferred 
embodiment and from the claims. 

SslsM. DescyipliiQTi of tjie Drawing 
Fig. 1 shows the symbol conventions used in the 
following figtires; 

Fig. 2 is a blocJe diagram showing a VCMS component 
overview; 

Fig. 3 is a block diagram showing a VCO 
architecture overview; 

Fig. 4 is a block diagram showing the VCO software 
architecture ; 

Fig. 5 is a block diagram showing the VCO client 
application software architecture; 

Fig. 6 is a block diagram showing the VCO class 
derivation; 

Fig. 6A is a table of the VCO exception handling 
modalities; ' 

Fig. 6B is a table of the VCO trace output 
modalities; 

Fig. 6C is a table of vco events which trigger 
notification; 

Fig. 7 is a block diagram showing the device 
control mechanism; 

Fig. 8 is a block diagram showing the VCO control 
methodologies; 

Fig. 9 is a block diagram showing the terminal 
output control flow; 

Fig. 10 is a block diagram showing the signal 
triggering mechanism control flow; 

Fig. 11 is a block diagram showing the event 
queuing and dispatching control flow; 

Fig. 12 is a block diagram showing the connection 
capability control flow; 
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Fig. 13 is a block diagram showing the capability 
and mode mapping control flow; 

Fig. 14 is a block diagram showing the call 
controller control flow; 
5 Fig. 15 is a block diagram showing the line 

disconnection control flow; 

Fig. 16 is a block diagram showing the line 
dialed, ringback, busy, and connected control flows; 

Fig. 17 is a block diagram showing the line ring 
10 control flow; 

Fig. 18 is a block diagram showing the call reset, 
mode setting, and mode restoring control flows; 

Fig. 19 is a block diagram showing the exception 
handling control flow; 
15 Fig. 20 is a block diagr£im showing the media 

control object command control flow; 

Fig. 21 is a block diagram showing the media 
device capability query control flow; 

Fig. 22 is a block diagram showing the media 
20 access control recjuest control flow; 

Fig. 23 is a block diagram showing the device 
event processing control flow; 

Fig. 24 is a block diagram showing the object 
construction and destruction control flows; 
25 Fig. 25 is a block diagram showing the "Open" 

command control flow; 

Fig. 2 6 is a block diagram showing the "Close" 
command control flow; 

Fig. 27 is a block diagreim showing the "Call" 
30 command control flow; 

Fig. 28 is a block diagram showing the "Multicall" 
command control flow; 

Fig. 29 is a block diagram showing the "Hang-Up" 
command control flow; and 
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Fig. 30 is a liable of the mul-tipoinl: control 
operations. 

Appendix: contianing source code for Virtual 
Device Interface Header File, 

5 Description of the Preferred Embodiments 

DEFINITIONS 

Provided below are definitions for terms used 
throughout this disclosure. While common technology 
parlance may assign a variety of alternative meanings to 
10 them, those definitions following refer to specific 
usages in this manuscript only, noted explicitly to 
alleviate ambiguous technology references henceforward. 

Transdueer 

This term refers to a device that converts one form of 
15 energy into another. Here specific reference is given to 
those that convert light and sound energy to electrical 
pulses, or inversely, electrical pulses back to light and 
sound energy. Examples include cameras, microphones, 
speakers, and video monitors. 

20 Signal 

This term refers to a digital data stream used to 
transfer raw or encoded binary information, except in the 
case of direct references to "bit-rate allocation signal 
indications . " 

25 Indication 

This term refers to a message connoting a change in state 
or modality of a system or station component; basic unit 
of notification used for the sole purpose of 
communicating the occurrence of some specific event. 



30 Notification 



wo 98/09213 



PCT/US97/15018 



- 15 - 

This term refers to an indication transmitted from one 
software component in the system to another software 
component in the same system. Typically used to notify 
software system components that some specific event has 
5 occurred and some response is required. , 

Spectral information 

This term refers to sound and light data that are 
represented as modulations of electromagnetic or audible 
spectra; audible and visible waveform information. 

10 Binary information 

This term refers to electrical pulse data encoded as 
binary numerical values that are typically referenced in 
octets . 

Terminal 

15 This term refers to as a physical or virtual teletype 
console device that displays text data outi>ut to it, and 
returns text input, such as if read from a keyboard 
device; essentially a dedicated text-processing I/O 
device or software representation thereof, with no 

20 significant processing ability. 

Station 

This term refers to an intelligent node on a network to 
which other network nodes can connect and exchange 
messages • 

25 Local station 

This term refers to the station whose resources are 
directly addressable without using an intervening network 
connection; conceptually perceived as the near-end of any 
connection. 
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Remote station 

nils term refers to the station whose resources are not 
directly addressable without an intervening network 
connection; conceptually perceived as the far-end of any 
5 connection. 

Sharing 

This term refers to bi-directional data transfer between 
interconnected stations on a network. 

Vendor«*8pacif ic 

10 This term refers to any hardware or software system 
component that requires a non-standardized software 
control layer to accommodate the particular recpiisite 
interface format and control procedures described by its 
manufacturer. 

15 ICultiaedia 

Thiis term refers to a class of digital computer ^ 
technologies that store, retrieve, manipulate, and play 
back audible and visual information. These technologies 
are embodied in combined software and digital hardware 

20 sub-systems that encode spectral information presented to 
input transducers, into digital data streams that are 
then stored in a compressed format. This compressed 
digital information is later reconstituted back to 
spectral information by decompressing, decoding, and 

25 subsequent retransmission through output transducers. 

Connectivity 

This term refers to the generalized concept of 
establishing a communications link between two or more 
stations on a network, exchanging messages according to 
30 some preconceived notion of structured interaction; this 
notion of interaction referred to as a protocol. 
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Multimedia connectivity 

This term refers to the generalized concept of 
establishing an audible, and/or visual communications 
link between two or more stations on a network; These 
technologies are embodied in combined software and 
digital hardware sub-systems that encode spectral 
information presented to input transducers, into digital 
data streams that are then transmitted across a network 
connection to a remote station in a compressed format. 
There it is reconstituted back to spectral information by 
decompressing, decoding, and subsequent retransmission 
through output transducers. When occurring bi- 
directionally in real-time, without delay, the connection 
between the stations is described as " live" , as if the 
input transducers of one station were connected directly 
to the output transducers of the other, and the network 
becomes conceptually irrelevant to the process. A variety 
of other media forms, such as still pictures and plain 
binary data, may also be exchanged between stations on an 
occasional basis, and played back as needed. 

Media Control Interface (MCZ) 

This term refers to a device driver Interface 
specification that allows its users to control underlying 
physical media devices using a somewhat well-defined, 
standardized string-token command language. 

Media Access Control (MAC) 

This term refers to that set of MCI drivers that provide 
a standardized physical device control interface layer 
between the more device-independent software layers that 
issue MCI string commands, and the vendor-specific device 
drivers that contain proprietary interfaces and control 
procedures to initialize, shutdown, and utilize the 
peripheral hardware components. 
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Object-Oriented Design 

This teinn refers to a methodology to enhance the quality 
of computer systems by describing their constituent 
components as discreet sets of related, well-defined 
5 operations whose implementations are isolated from their 
functionally described operational profiles; interactions 
between system software components are defined with equal 
precision, according to a specialized software 
development methodology* Highly-structured programming 

10 languagesl and design tools promote creation of modular, 
reusable software components that can be recombined to 
build new components; existing components are better 
understood in terms of functionality and reliability. In 
this way, implementations of new components borrow the 

15 functionality (and demonstrated reliability) of 

preexisting software technologies to create new products, 
thereby significantly reducing development time and 
dramatically improving overall system reliability. 

OPERATING SYSTEM MODEL 

20 A more accurate technical description of the VMCS 

is that of a Virtualized Multimedia Connectivity 
Operating System. Designed for a multithreaded, protected 
memory model implementation, the VMCS server component 
runs parallel to the client applications that utilize it, 

25 the server responding to client requests with a stream of 
notifications directed to class objects located in the 
client progrsuas. A client application invoking a VMCS 
server, spawns a concurrent operating system that 
effectively manages all hardware and software components 

30 necessary to establishing a device- independent multimedia 
connectivity service, in much the same way as any 
operating system does to support its general application 
programs. Once created, the VMCS server runs by itself, 
independent of the client, and capable of offering 



wo 98/09213 



PCT/US97/15018 



- 19 - 

services to more than one client at the same time. Just 
as with advanced operating systems, the transactions 
between clients and servers are fully protected, and 
highly structured with regards to both syntax and 
5 sequence. The VCO Client selects an "operating system" 
that best suits the system hardware configuration, 
invokes it when needed, discards it when it is no longer 
needed, and changes it when it prefers an "operating 
system" with a different service profile. 

10 consistent with the intention of its design, 

multiple VMCSs can be concurrently invoked. The VMCS, in 
accordance with the "operating system" model heretofore 
described, was intended from its inception, for 
implementation in multiprocessor or distributed systems 

15 where a separate coprocessor, parallel processor, or 
entire system could house the server component 
separately. Fiirther, embedded implementations (for use 
with coprocessor systems) do not pose the usual 
implementation difficulties associated with sub-system 

20 designs whose client and server component were assumed to 
reside in shared memory. 

STANDARDS COMPLXANCE 

There is a well-defined modality of interaction 
between VMCS servers, and the VMCS applications that use 

25 them, the orders of whose operations are specified with 
mathematical precision. Resultantly, there is a high- 
degree of predictability in the progression of 
connectivity sessions, and corresponding measurable 
improvement in their robustness. VMCS implementations 

30 are unique in the domain of multimedia connectivity 

systems. Specifically, they make possible the creation 
of standardized software communication products, enable 
connectivity applications to run over any compliant 
connectivity sub-system, fully integrate audiovisual/data 
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connectivity services into a single control mechanism, 
reduce software development tine, and expose 
extraordinary levels of derived functionality. 

This methodology is primarily a software 
5 development technique. Object-oriented software 

components are created to abstract the low- level services 
of media control and network interface components to a 
fully-virtualized multimedia connection service that 
integrates the ITU-T multimedia interconnection protocols 

10 (H. 320), the Open System Interconnection (OSl) Reference 
Model, and object-oriented software design principles. 
The VMCS architecture combines these paradigms into a 
dynamically instantiable client-server multimedia 
connectivity service technology. ITU-T Recommendation 

15 H.320 defines a discreet set of operations and procedures 
necessary to the sharing of spectral and binary data 
between compliant interconnected stations. It enables 
reliable, structured data transfer and device mode 
synchronization testations connected to the Integrated 

20 Services Digital Network (ISDN) . A VMCS implementation 
employs the ubic[uitous H.320 recommendation as a rigorous 
definition of its most basic set of multimedia 
connectivity operations. For stations that access the 
ISDN, this application of H.320 is natural and obvious, 

25 but the VMCS goes on to take further advantage of the 
apposite H.320 structure. The VMCS architecture insists 
upon the promotion of the H.320 protocol set to that of a 
universal framework to which even non-compliant protocols 
can be promoted. 

30 ARCHITECTURE 

CSX REFERENCE MODEL 

Connectivity system developers can abstract the 
presentation of non-compliant services to a 
representation more efficiently managed by applications 
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(that are typically unconcerned with the specific 
requirements of the control mechanisms). The Open System 
Interconnection (OSX) Reference Model defines a layering 
model offered internationally as a generalized system 
5 architecture to affect the designs of connectivity 
software systems, particularly with respect to host 
stations desirous of reliable interconnection. For any 
host operating system (OS) , a Virtualized Multimedia 
Connection System (VMCS) provides an exact definition of 

10 the OSX Presentation Layer that serves as the interface 
between a connectivity application (client) , and the 
connectivity sub-system (server) . The majority of 
software components, common to all VMCS implementations, 
are reusable versions of the services specified to reside 

15 in the OSI Session Layer; they provide device-independent 
implementations of the protocols represented by the H.320 
rubric. Media control and network interface 
manufacturers are usually best qualified to supply low- 
level device/protocol support drivers that comprise the 

20 OSI Transport, Network, and Data Link Layers. The VMCS is 
most efficiently implemented when it leaves this task to 
them, and instead builds on their work* For specific 
media control and connectivity tasks, it is often 
indeterminate as to whether a device, or software 

25 component, will comprise the best utensil. Since the OSI 
Reference Model is functionally specified, a system 
developer has the flexibility to derive a VMCS sub- 
component, or entire OSX Layer, in a way that best 
supports its design specification, regardless of whether 

30 it is build with existing or newly created sub- 
components . 



OB JECT*ORl ENTATION 

Both VCO Client and server software components are 
developed with an object-oriented programming language. 
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according to a precisely-defined class inheritance and 
derivation hierarchy. A binary software object is created 
to encapsulate disparate software components into one 
fiinctional entity, whose services are available only 
5 through structured access of its control elements (member 
functions and member data) . The strategy of all VMCS 
designs, derived by the application of this methodology, 
is to encapsulate media control services, connectivity 
services, and protocol support components, together, in a 

10 way that best integrates their properties into an 

instance of a standardized multimedia connection service 
to be used by device- independent client applications. 
Specific protocol support procedures, and media control 
components, are shared by all VMCS implementations; 

15 usually they are worth preserving, fine-tuning, and 
carrying forward to new implementations. VMCS 
implementations created to support new hardware 
configurations are most accommodating to this 
circumstance, to the extent that they are typically minor 

20 modifications of a reference VMCS implementation. New 
VMCS implementations may be designed in one of three 
modalities. First, a VMCS can be developed to exploit the 
services of an existing multimedia connectivity product 
(hardware and software sub-system layers) manufactured by 

25 a third party. Such a project would restructure 

proprietary controls of the native interface, coercing 
(virtualizing) them to the structured consistency defined 
by the VMCS paradigm. A second modality is to create a 
presentation of the defined VMCS services for a new 

30 device set, creating all device control components, VMCS 
components, and perhaps the devices themselves. Lastly, 
designs can, at run-time, invoke a particular 
presentation of services, derived from the ad hoc 
association of media control devices with selected 
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connection services, in a way most suitable to producing 
a desired multimedia connectivity service profile. 

CLXEKT/SSRVBR MODEL 

Notwithstanding the flexibility afforded by 
5 software implementations, it is useful to describe the 
works of the VMCS in terms of discreet, mechanical 
components. There is no requirement for any component to 
be implemented entirely in hardware, or entirely in 
software, per se, so the distinction will not be brought 
10 to bear on this discussion* There are two major 

components in any VMCS: the multimedia connection sub- 
system (server) , and an application program that invokes 
its services (client) . Any VCD Client application can 
invoke the services of any server, without hesitation, 
15 with a guarantee of compatible access . More nebulous is 
the parity between the quality of services requested by 
the client, and those provisioned by physical devices 
encapsulated in the server* Strictly speaking, the server 
is the binary software object that encapsulates the media 
20 control and connectivity sub-system* It is referred to as 
a virtual Connection Object (VCO) , and the client 
application that invokes usage of its services, is 
referred to as a Virtual Connection Object Client 
Application (VCO Client) . In this section, the scope of 
25 the discussion will be limited to a functional 
description of these entities* 

SERVER COMPONENTS 

Virtual Connection Objects are binary software 
objects that encapsulate the media control and 
30 connectivity components requisite to the implementation 
of a discreet subset of multimedia connectivity services* 
They are invoked and adjusted by manipulation of their 
members* When constructed, a VCO dynamically builds the 
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particular operational context of hardware and software 
components needed to best implement virtualized 
multimedia connection services. Destruction of the object 
deletes this operational context by shutting down all 
5 components, turning off devices, and releasing any 
allocated resources. For the host OS, every 
Implementation of such an object presents members that 
are identical in syntax,- structure, and usage. In fact, 
every VCO is functionally analogous in its control 

10 mechanism, but unique in both its name, and the degree to 
which it is able to realize the full set of VMCS services 
defined to be represented in every instance thereof; that 
is each VCO has a unique set of capabilities . Inherent to 
every VCO, is the ability to provide metrics describing 

15 the potential quality of services locally available, and 
the actual quality of services available while connected 
to a particular remote station. The service profile of 
the unconnected local station is available prior to 
device initialization (but after VCO construction) , for 

20 casual examination by interested VCO Clients; this 

profile is referred to as the Local Capabilities. The 
service profile of a remote station is available while it 
is connected to the local station, and this profile is 
referred to as the Remote Capabilities. Also available 

25 when connected, is the service profile of the connection 
itself, referred to as the Connection Capabilities. This 
is the preeminently useful metric, and quantifies the 
potential quality of interactions between the local and 
remote stations; precisely, it is the logical 

30 intersection of the local and remote capabilities. 

A real-time reporting mechanism alerts system 
software objects of changes in the specific states, 
modalities, and conditions critical to the operation of 
the encapsulated multimedia connectivity sub-system. The 

35 basic unit of information, or indication, is referred to 
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as an Event, and each VCO contains a specialized delivery 
system that can notify software components in the host 
system when one such event has occurred; a Notifier 
Object is the mechanism for this delivery. Notifier 
Objects are triggered by the occurrence of any event type 
to which they are programmed to respond, and they are 
used both internally by the VCO, and externally by its 
clients. Finally, it should be pointed out that a VCO is 
implemented to present the services of one particular 
configuration of media control /network interface setup 
that comprises the multimedia connectivity sub-system, 
and it is likely each significantly different hardware 
and/or software configuration will require a somewhat 
different VCO implementation; a VCO is a device-dependent 
entity . 

CLIENT COMPOKESTS 

Applications programs described in the VMCS are 
referred to as Virtual Connection Object Clients, are 
device- independent, software application programs that 
invoke VCOs, and manipulate their members to control live 
information-sharing sessions with remote stations; to 
that end, they create use-specific logical combinations 
of currently available audiovisual /data resources to 
support a defined set of multimedia connectivity tasks 
that is the embodiment of that particular connectivity 
application. They are developed in an apriori fashion, 
according to a concise, multimedia connectivity software 
control interface specification, the integral 
implementation of which each VCO must contain. Clients 
dynamically invoke at least one appropriate VCO, selected 
(from a library) according to some notion of suitability, 
and then construct it only when a connectivity session is 
actually to be initiated. VCO Clients create instances of 
Notifier Objects, and utilize them as a mechanism to 
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respond (jnore-or-less instan1:aneously) -to occurrence of 
divers events to which they have been rendered sensitive. 
A client software object that contains member functions 
to receive, and respond appropriately to, these signaled 
5 events, is referred to as a Notification Receiver Object. 
Clients may monitor and/or intercept connectivity and 
device control related occurrences in the encapsulated 
sub-system, by creating- instances of VCO Notifier Objects 
with specific response profiles. These Notifier Object 

10 response profiles may be reconfigured ad hoc; they define 
the set of specific events that will trigger 
notifications (when a specified event occurs) to one 
identified NRO. There can be only one NRO associated with 
a particular instance of a Notifier Object. In a given 

15 host OS, any VCO Client can function using any VCO; a VCO 
Client is a device- independent entity. 

METHOD 

Here follows description of a method to implement 
a preferred embodiment of a Virtualized Multimedia 

20 Connection System (VHCS) • The scope for the disclosure 
will be restricted to an elucidation of those elements 
required to derive a design specification for a fully 
device-independent multimedia connection system; a system 
to be built from third-party media control devices, 

25 device drivers, and a connectivity protocol stack running 
over a network interface unit. All VHCS software 
components are created with an object-oriented 
programming language (see M.A. Ellis and B. Stroustrup, 
The Annotated C++ Reference Manual, Reading, 

30 Massachusetts, Addison-Wesley, 1990) • Attendant source 
code provides a precise definition of the host/client 
software interface, and an example of a simple, portable 
device- independent connectivity application. 
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The design of this system will be considered 
initially from the perspective of an overview, and 
subsequently as a functional examination of its component 
interworkings. Next comes a detailed examination of 
critical software and hardware constructs needed to 
physically implement a VMCS design. The topic concludes 
with a discussion related to the deployment of a working 
system in an actual host computer system. For this 
section in particular, the examinations of system details 
remain more generalized in the start, and are more fully 
later resolved, the strategic intention to permit a 
system engineer to piirsue a top-down design approach for 
his particular VMCS adaptation. Compliant designs will 
produce products supporting exact binary compatibility 
between every VMCS created for the same target operating 
system, and exact functional compatibility between every 
VMCS, regardless of the target operating system. 

DESIGN 

VISUAL TELEPHONB SYSTEM MODEL 

The creation of a visual telephone system is the 
most likely application for a VMCS implementation. Such 
a system illustrates all of the basic components that 
comprise the set of media control, network interface, and 
software control features common to most such solutions 
now available. The ITU-T describes a generalized model 
for this type of system in a document referred to as 
Recommendation H.320. This discussion, as related to a 
VMCS implementation, is best served by a similar 
treatment of the subject, as it relates to the task of 
deriving a virtualized model of multimedia connectivity; 
the VMCS software abstraction represents the functional 
aspects of the generalized visual telephone, with some 
notable extensions to its base level utility. It must 
also be pointed out that a VMCS implementation in no way 
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relies upon the ITD-T recommendations below the level of 
the signal and indication protocols specified by H.320 — 
any network or connectivity sub-system could conceivably 
be adapted as the underlying network transport layer* 

5 EIiEMSNTS OF A VISUAL TEIiEPHONE SYSTEM 

The prototypical VMCS system relies on divers 
hardware and software components to transfer audio, 
motion**video , still pictures (images), and binary data 
objects between stations connected to the same network. 

10 Devices and control systems described below should be 
considered in terms of being functional entities; the 
potential to support device characteristics with a 
software emulation module is an implementation 
alternative that does not alter the basic strategy of 

15 VMCS design. In fact, input from, or output to a 

transducer device can be simulated by a data streaun read 
from, or written to backing store. 

Z/O Equipment 

These devices are referred to as transducers in 
20 that it is their primary task to convert energy forms 
from spectral to pulsed electrical, or vise-versa. In 
practical terms, these devices are the only parts of the 
system with which the user interacts directly. 

• Audio devices include stationary microphones 
25 and related sound detection equipment to 

input the voice of the user. For output, 
loudspeakers and headphones are output 
transducers in a VMCS. 

• Video devioes include a camera to input 

30 motion-video images of the user. For output, 

video monitors display motion-video, as do 
dedicated analog (NTSC/PAL) video displays 
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Image devices Include a camera to input 
images, as well as scanners to capture high- 
resolution images/ For output, video monitors 
display images, and in addition/ printers 
that can render images are considered output 
transducers • 

Data devices do not convert energy forms, but 
are essentially "locations" in the system 
through which data flows, or in which it is 
stored. Data devices include any backing 
store (disk) entities, or data ports, such as 
a communications port. Dedicated data 
streams, or "socket" interfaces would also 
c[ualify as valid VMCS inputs /outputs for 
binary data. 



CODEC 

These devices compress data from input transducer 
devices prior to transmission or storage, or inversely 
decompress data following transmission from a remote 
20 station or retrieval from storage. The process of 

compression is referred to as encoding, as spectral data 
is encoded according to an algorithm; decompression is 
correspondingly referred to decoding. Visual telephones 
transmit and receive audio and video data in a compressed 
25 format so as to enhance the efficiency of the system in 
its endeavors to exchange large volumes of audio and 
video data across connections that only support a very 
limited bandwidth. Storage of images to disk proceeds in 
the same way to reduce the amount of storage space 
30 required. 

• Audio de/ compression devices are typically 
incorporated together with H.221 
encoding/decoding hardware used for video 
processing; audio compression and 
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decompression are of 'ten accomplished in 
software . 

• Video de/eompression for live moi:ion-video 
conferencing is best accomplished with 

5 hardware specifically designed for H.221 

encoding/decoding; video compression in 
software (for high quality video) is 
typically unsatisfactory. 

• Image de/ compress ion for images is typically 
10 done in software according to a specialized 

algorithm (such as JPEG) or transmitted as a 
simple bitmap. 

• Data de/ compress ion is typically not 
required, save only when the data object 

15 itself has been compressed prior to 

transmission, as part of a separate 
operation* 



Telematie Ecpaipment 

These are facilities (devices or software 
20 components) that act a visual aids to enhance 

conferencing. Application sharing features, common 
whiteboards, and image transceivers are included in this 
category, as are scanners and facsimile devices attached 
to communications ports on the visual telephone station. 

2 5 Hul t iplezors / Demul t ip lexor s 

Signal multiplexing and demultiplexing operations 
are typically combined into a single hardware device that 
combines the audio, video, and related data streams to 
the single H.221 frame structure (multimedia signal) used 
30 in line transmission, and restores them to their 
constituent data streams upon receipt from a remote 
station or storage entity. 
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Network interface 

This component is typically a hardware device that 
provides the physical connection between the host station 
and the network, though software simulations may provide 
5 an emulated version of the same. 

Network 

Any transport medium supporting actual or emulated 
line transmission of the H.221 signal and indication 
portion of this protocol, and capable of synchronous (and 
10 simultaneous) audio, video, and binary data transport. 
Examples of recommended network types include the 
following: 

• ISDN (Basic and Primary Rate Interfaces) 

• B-ISDN (Using ATM) 

15 • LAN (FDDI and high-bandwidth proprietary 

technologies) 

• Mobile/Radio (and other wireless) 

• Analog (PSTN) 

Multipoint control Unit 

20 This is a specialized device whose functionality 

is described by ITU-T Recommendations H,24 3 and H.231. 
The functionality of this device must be available for an 
implementation of a VMCS that is fully capable of the 
entire set of VMCS-defined multipoint control operations. 



25 System Control 

The VMCS is an implementation of this (system 
control) visual telephone system component, but conceived 
as a more generalized model suitable for utilization in a 
broad range of concurrent audiovisual /data sharing 
30 applications. The VCO component of the VMCS allows a 
device- independent connectivity client application to 
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Utilize any audiovisual device control system services 
related to those of the defined visual telephone system. 

YZBJJKL CALL PROGRE8SZOK 

A VMCS session takes the form of a visual 
5 telephone call. This interconnection procedure is 

precisely defined, and permits interoperability between 
dissimilar stations sporting diverse equipment 
complements, while retaining compliance to ITU-T 
Recommendation H.320. it would not be possible to utilize 

10 the plethora of potential operating modalities of VMCS 
systems without a thorough categorization of the set of 
all those modalities known to be supported by the local 
station' s equipment configuration. Further, each station 
participating in a connectivity session (call) must come 

IS to an understanding of the modalities supported by its 
counterpart at the other end of the connection. What 
ensues at the time of the call is a plaimed negotiation 
that pits the performance expectations of the local 
station (as to the set of operating modalities it would 

20 ideally prefer to assume during the session) , against the 
cataloged limitations of its remote station peer; a 
common set of operating modalities they both must co- 
operatively determine and ultimately share for effective 
audiovisual communication. 

25 Establishment of visual Telephone Call According to H.320 

Shown below are the basic steps common to 
establishing a "normal" visual telephone call. This 
sequence is idealized in that it does not suffer 
interruption or complication as frequently occurs in 
30 actual use. Notwithstanding the inevitable anomalies 

encountered during live operation, the following sequence 
provides a model for call progress; one that must be 
implemented by every VMCS connectivity sub-system, and 



one derived directly from the ITU-T visual telephone call 
procedure as follows: 

1) Call setup, out->band signaling (H.200) 

A request is made to the network for a 
connection to a remote station. Indication is 
received at both ends to indicate when this has 
occurred, and a bi-directional data channel from 
end to end is opened for use. This data channel 
carries multiplexed multimedia data between the 
stations. A device-independent call control 
mechanism is integral to all VMCS server 
components (Virtual Connection Objects) and 
operates directly to manage the call states iand 
related operations required to create the 
connection and data channel. 

2) Mode initialization on initial channel (H.242) 

An exchange of device capabilities takes 
place once the connection is created and frame 
alignment for the data channel is achieved. It is 
at this time that the VCO call controller 
initiates sending its own capabilities to the 
remote station. It also receives and stores 
— — capabilities sent from the remote station. A 

common base-level audio mode is selected., by the 
stations according to availability indicated by 
the exchanged capability sets. In the VMCS, any 
connection established must engage in the exchange 
(or emulate the exchange) of a capability set. A 
minimal bi-directional data channel must also be 
established in this phase. A capability exchange 
between stations can be initiated from either end, 
and may reoccur at any time (while connected) to 
assert a new ability recently assumed by a 
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Station; a device may be turned on or off during 
the session^ thus changes the stations capability 
profile. 

3) Call setup of additional channels (if used) 

5 Though not always used, the VCO supports 

connections of two separate lines. While network 
configurations may use six or more separate lines 
for a call, they are typically bonded together as 
one call and thus appear as a single line call to 
10 system call control. Call setup for additional 

lines proceeds in an identical fashion to that for 
the initial channel. 

4) Initialization on additional channels (if 
used) 

15 Though only used if additional channels have 

been established, capability exchange and mode 
selection proceeds as for the initial channel. 

5) Establish conmon parameters (H.242) 

Both stations have available a list of the 
20 other's capabilities. Each VMCS has associated 

with it, a specific conference profile parameter 
that is used to specify the operators preferred 
operating properties. Examples include a bias 
towards better video quality, or better audio 
25 quality. Coupled with this profile is a set of 

operating modalities that can be supported by both 
ends of the connection, and the preference of the 
remote operator. According to the physical 
limitations of the remote station's device 
30 capabilities, and in hopeful compliance with the 

preferences of the operator, a device mode 
negotiation mechanism seeks to algorithmically 



wo 98/09213 



PCTAJS97/15018 



10 



- 35 - 

deduce the most suitable set of device modes for 
the call by interacting with the remote station to 
realize them. 

6) Visual telephone eoamuiiioatioii (H.261} 

This phase refers to the fully established 
session itself, whereby audio, video, and binary 
data exchange can" take place over existing data 
channels. The H.320 Recommendation states that 
visual and audio communications must be active in 
this phase, though the VMCS allows for idle 
connections during which time no data exchange 
takes place; that is audio and video may be 
disabled, while the connection is still 
technically active. 

15 7} Termination 

When one user hangs up, an indication is sent 
to the other end to signal termination of the 

the form of disconnection signals for all 
lines. Such action by one end, initiates the call 
termination process; the initiating station shuts 
down all of its data transmission to the remote 
station. Out-band signaling is typically used for 
the purpose of disconnection. 



20 



25 



30 



8) call release 

Once termination has been initiated (when the 
other end receives this message) the station sets 
data transmission to idle for each disconnected 
channel, when all lines in the call have received 
disconnection events and been set to idle, the 
call is considered to be disconnected. Individual 
lines can be added or removed as needed, without 
disconnecting the entire call. 
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VMC8 SYSTEM OVERVIEW 

FIG. 2 depicts an overview of the major components 
of a Virtualized Multimedia Connection System. There are 
four significant entities shown: The Virtual Connection 
5 Object (VCO), the Virtual connection Object Client 

Application (VCO Client) , I/O devices, and the network. 
The VCO and the VCO Client are the subject of this 
disclosure. The I/O devices are connected with a direct 
physical link to adapter boards in the host system that 
10 permit the physical control of the I/O devices via device 
driver. Essentially, the only link the VCO has to these 
devices is through a vendor-specific Media Access control 
software layer (or some other device driver) , and the VCO 
link to the network interface unit is through a 
15 standardized, or vendor-specific network protocol stack. 
The network protocol stack shown in the drawing is likely 
some OSI Transport Layer abstraction of a connection 
service. 

Summary of VMCS System overview 

20 From a conceptual standpoint, the VCO combines the 

services of the data transfer (network) service with 
associated media transducer devices, so as to reliably 
offer system command and control of a derived multimedia 
connectivity service to an application program. There are 

25 two primary components of any VMCS; they are as follows: 

• The Virtual Connection Object (VCO) 
encapsulates all of the server components 
that are required to abstract a virtualized 
representation of the media control and 

30 connectivity sub-systems, offering it to 

device- independent connectivity clients. 

• The Client Application (VCO Client) 
constructs and utilizes the virtualized 
multimedia connection services hidden away 
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inside the VCO by manipulating its xttember 
functions and member data. There are a number 
of specific objectives motivating this 
object-oriented system design, the substance 
of which receives commentary below: 

system Design Objectives 

Design-level support for VMCS Services 

The objective of the VMCS design is to provide 
design-level support for a full virtualization of any 
multimedia connection system, so that device- independent 
representations of a logical control mechanism could be 
ported to a wide variety of supporting media control 
devices and network interface. Client applications 
designed to utilize VMCS technology are interoperable 
with every VCO implementation (running under the same 
operating system) and thus more efficiently distributed, 
maintained, supported, and redeployed with new device 
complements. Most important is the ability to bind any 
network interfaces to any media control interface by the 
addition of specialized hardware and software layers that 
combine the functions of these components without 
affecting its mechanism of control. New and different 
underlying technologies are well utilized, however the 
extensible VMCS virtualization paradigm leaves their 
often peculiar operating procedures fully obscured from 
the view of application programs. 

Progressive Isolation of Sub«*system from Applicatiojis 

The VCO component of the VMCS incorporates a 
number of design methodologies whose purpose is to 
dissociate the control of services, from their physical 
implementations. The Open System Interconnection (OSI) 
Reference Model (see B. Hebrawi, OSI Upper Layer 
Standards and Practices, New York, NY, McGraw-Hill, 
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pp. 11-15, 1993) and object-oriented programming languages 
are primary building blocks in any VMCS. 

• OSI Layering underpins the structure of the 
VMCS in that the VCO is a logical 
encapsulation of all of the OSI layers below 
the presentation layer. The VCO members 
themselves comprise the OSI Presentation 
Layer implementation, whereas device- 
independent routines in the upper VCO layers 
form a discreet and reusable OSI session 
layer . 

• Class Structure of the VCO is rigidly defined 
so as to preserve the largest number of 
functional source components from 

15 modification, and to maintain the design 

integrity of the VMCS. Class components 
allow for a definitive specification of 
distinct, isolated functional units that will 
not affect their interactions with related 

20 components when their internal 

implementations have been modified to 
accommodate the operational characteristics 
of vendor-specific components. 

• Discreet Member Profile preserves the 

25 modality of the interface that makes each and 

every VCO implementation appear the same to 
clients, and consequently it is most 
essential to maintain its form to enable 
interoperability for all clients. VCO 

30 Clients assume that the specific member 

profile of every VCO is identical, thus each 
can be invoked and utilized without concern 
for incompatibilities between them. 

• Token-based Job Description Language is a 
35 text-token representation of the VCO member 
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functions and their highly structured 
enumerated arguments • If the structure of the 
VCO interface is consistent (over time) and 
reducible to simple string commands, then it 
5 is possible to reduce the control of any VCO 

to a series of text messages in a character 
stream. From this approach is derived the 
capacity to remotely control a VCO. User 
applications are almost entirely isolated 
10 from the server component in that each server 

(VCO) functions as a command interpreter. 

Client Components 

The VCO client in FIG. 2 is a device- independent 
layer that is dynamically portable at run-time to other 

15 VCO-encapsulated multimedia connectivity sub-systems - All 
VCO Clients are fully interoperable with all server (VCO) 
layer components that offer a consistent presentation 
(OSI Presentation Layer) constructed according to an 
interface specified in this document. Notification calls 

20 from the VCO to the client can occur spontaneously, 
asynchronous with other system events, and concurrent 
with notifications emanating from other VCOs invoked by 
the same client, thus most client modules should be 
designed to support re-entrancy and mutual-exclusive 

25 access to resources. A multithreaded implementation 

strategy is most efficient to manage the various, often 
concurrent tasks related to simultaneously maintaining 
the visual information presented to the user, and 
supporting the command, control, and real-time monitoring 

30 of the multimedia connectivity sub-system. Regardless of 
the frequency of device interrupt requests or the rate of 
message passing between interconnected stations, the flow 
of notifications from the VCO to the client is conducted 
according to a dynamically configurable interval that a 
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Client can optimize according to its particular needs. In 
reality, the client runs at operating system speeds 
determined by the system scheduler, while low-level 
device control components in the VCO run at device speeds 
determined by the network and the devices themselves. 
Resultantly, VMCS systems share the following 
characteristics: 

• Applications can vary the periodic rate at 
which they are actually notified of device 
events occurring sporadically, in real-time 

• Applications never miss events, and are never 
unable to respond to them due to their 
occurring in time slices not allocated to the 
application. The VCO notifies its client 
application that a particular event has 
occurred, by scheduling the application to 
run, in response to that event, on a special 
thread created by the VCO event dispatcher. 

• Application processing of device events 
catches up to the rate at which the device 
produces them, by continuing to send 
notification of events to the application 
during I/O latency periods when the device is 
less active. 

• Critical section handling, as related to 
device interrupts and the management of 
device driver queues, is fully managed by the 
VCO, thus the application may process 
notification events at a high-level; it is, 
by design, nearly in^ossible for an 
application to corrupt the timing and real- 
time operation of the low-level device 
control sub-system. The application sees 
these sub-systems as a stream of interesting 



wo 98/09213 



PCT/US97/15018 



- 41 - 

events, none of which requires attention for 
proper VCO operation. 

Application Shell 

The application shell is preferably an event- 
5 driven graphical user interface (GUI) program written in 
an object-oriented prograimning language. There are no 
special considerations for VMCS integration. Retrofitting 
of existing GUI programs, to work as VCO Clients, is 
easily accomplished. In fact, any application shell that 

10 constructs a VCO is defined as a VCO client, and only a 
modicum of member functions need be called to establish a 
fully operational connectivity session to a remote 
station. A daemon that constructs a VCO, and fields 
string commands from a hardware or software data port, 

15 can serve as a non-interactive VCO client. 

Notification Receiver Objects (MRO) 

These software objects are created to provide a 
structured mechanism for responding to VCO events. Any 
application class object can contain a specific memb^ar 
20 function and adjunct function mapping component to direct 
the VCO to send a notification message to that object 
upon the occurrence of any set of specified events. 

VCO Components 

The VCO utilizes a three-layer software design 
25 that converts the native modalities and properties of 
some set of physical devices to those that can be 
accurately described using the parameters specified by 
the VCO. Underlying the software components are device 
control components used to physically operate the media 
30 control and connectivity 'sub-systems . These low-level 
components , and the devices that they control, sore 



wo 98/09213 



PCT/US97/15018 



- 42 - 

typically provided by a third party specializing in their 
respective technologies. 

Virtual Device Interface (VDI) 

Provides a logically-defined, or virtualized 
interface to services that would be offered by an 
idealized, functionally advanced combination visual 
telephone/ imaging system. The VDI is a reusable shell 
that is common to all vco implementations (in a given 
OS) . 

Virtualization Layer (VL) 

Translates logical operations defined in the VDI, 
to physical implementations (of those most similar) 
provided by the PDI. The VL is set of mostly reusable 
routines that are, as needed, partially reimplemented to 
work with a particular device set in the PDI. In many 
cases, VL components may include direct accesses to 
vendor-specific connectivity protocol stacks and media 
control components . 

Physical Device Interface (PDI) 

Provides a physical, or driver-level interface to 
actual physical devices assigned to the control of the 
VCO implementation. The PDI inherits virtual izat ion 
fxinctions from the VL to provide a rigidly compliant 
implementation of a device control interface used by the 
VDI directly to provide support for its logically defined 
tasks. PDI implementations include direct accesses to 
vendor-specific connectivity protocol stacks and media 
control components . 

Encapsulated Devices 

The encapsulated devices in a VMCS typically 
include a network interface unit and a host of related 
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media control devices. The connectivity protocol stack 
refers to the software layers necessary to provide 
services defined for the OSl Transport Layer; that is, it 
must ensure the reliable transfer of messages between end 
5 users. Media Access Control must contain drivers enabling 
physical operation of all devices relegated to VCO 
control, as previously specified in the section entitled 
DEFINITIONS. The types of devices likely to be 
incorporated into the VCO design, will be some variation 
10 upon those described to manage audio, video, images, and 
binary data, as specified in the section entitled I/O 
Equipment . 

Component Interactions 

There are well-defined modalities of interactions 

15 between VMCS components. The VDI makes direct use of PDI 
members to invoke the services of physical devices in its 
mission to fulfill VCO Client requests for services. The 
PDI, in turn, calls functions in the connectivity 
protocol stack and in the Media Access Control layer. The 

20 PDI calls member fxinctions in the VL to provide the 

mapping, translation, and formatting necessary to coerce 
the low-level services to resemble those logically 
specified by the VDI. As they occur in real-time, events 
generated by the connectivity protocol stack and Media 

25 Access Control components are added to a general VCO 
event queue . A dispatcher in the VCO removes events 
periodically, synchronous with the operating system 
scheduler. An event processor in the VL responds to 
events as they are dispatched to it, invoking other VCO 

30 components as needed. Some of these events require that 
the client application be notified of their occurrence, 
if the client has so arranged. 
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VCO XUflGHITECTDHAL OVERVIEW 

FIG. 3 depicts a functional block diagram of a 
VCO> with components partitioned according to the vco 
layer where they reside. This section provides a high- 
5 level view of the VCO sub-components' functional 

organization. Subsequent sections pursue a more rigorous 
examination of the constructs themselves, here only 
topically considered, it is more important to note that 
the VDI, VL, and PDI sections labeled "Device /Protocol 

10 Controllers" are to be considered as layer-specific 

overlays of the same groups of components. The groups in 
the VDI section "Device/ Protocol Controllers" illustrate 
the logical definitions for each of ten distinct 
functional categories; corresponding groups in the YL and 

15 PDI describe the identically functional categories, but 
at a different level of software abstraction. All 
components in the VDI section are fully reusable, device- 
indeipendent software components. Those components in the 
PDI are vendor-specific and implementation-specific while 

20 those in the VL are mostly device- independent, but may 
require some implementation-specific coding to support 
wide variations in the underlying device control 
software. 

Software con^jonents in the VCO are physically 
25 divided into very specific object entities, each of which 
much interact with those adjunct and adjacent. A set of 
related functions and data structures combine 
synergist ically, are referred to as a controller. Such 
entities are the basic functional units of the VCO in 
30 that they form discreet functional "parts" that control 
and/or manage a well-defined set of tasks. 



Summary of VCO Arohitaotural overview 

The VCO is a single binary software object that 
encapsulates all of the hardware and software components 
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necessary *bo implement: a fully Vlrtualized Multiimedia 
Connection System. Virtual izat ion of the services 
provided by disparate connectivity and media control 
systems is rendered according to three-layer progressive 
abstraction strategy that relies upon object-oriented 
software technology for both its design and 
implementation. 

• A device- independent, reusable software 
layer call the Virtual Device Interface (VDI) 
is created to provide a detailed logical 
description of a virtualized multimedia 
connection service. It has as set of public 
member functions that define its interface to 
applications and other invoking software 
modules. Included in this layer are a series 
of software controllers that ajr& specifically 
here located (in this logical layer) to 
embody the larger part of the system' s 
software implementations in a layer that 
would be directly propagated to new system 
implementations, wherefore to facilitate the 
creation of a highly reliable, reusable, 
portable modules. 

• A mostly reusable, and predominantly device- 
— independent intermediary software layer 

called the Virtualization Layer (VX>) is 
created to assist in the process of 
translating and mapping the functions of 
various device control mechanisms employed by 
the underlying connectivity and media control 
sub-systems, to the logically defined virtual 
representation required by the VDI. 

• A device-dependent layer called the Physical 
Device Interface (PDI) interfaces directly to 
the device control sub- system to provide a 
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physical implementation to the service 
requested by the VDI, The PDI makes use of 
virtualization functions in the VL to coerce 
the particular message and data output 
5 formats of vendor-specific device control 

components, to a structured format integral 
to the VCO design. 
• Audiovisual and binary data streams in the 
PDI sub-system are represented as Media 
10 Control Objects (MCO) . A list of these 

objects is maintained by the PDI so as to 
present the VCO with a pool of available 
media device and signal resources. According 
to the media type, and its direction of flow 
^5 in the system, these MCOs are classified 

accordingly as either an audio, video, image, 
or binary data type. They are further 
characterized as a signal from the remote 
station, to the remote station, to a local 
20 output device, or from a local output device. 

Operations performed on these objects modify 
their properties and modalities of 
interaction, so as to provide the VCO with a 
logical software switching mechanism for its 
25 encapsulated media control device inputs and 

outputs . 

Virtual Device Interface 

The device- independent portion of the VCO, is a 
fully reusable entity that is created once, and then 
30 propagated to all VCO implementations. It contains the 
definition of all the VCO public member functions 
accessed by clients. These members are collectively 
referred to as the Software Control Interface (SCI) , 
which itself includes a number of other VCO control 
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mechanisms whose functionality extends well beyond simple 
calls to members. The VCD event notification mechanism 
and terminal stream I/O manager are integral to the VDI, 
as are ten controllers related to implementation of the 
5 services requested through calls to SCI members. 

Software Control Interface Functional Groups 

These groups of "control members" contain the 
member functions used by clients to invoke VCO services. 
Each relates to a set of public VCO member functions used 
10 to access a specific class of well-defined operations. 

• Svent Notification Control Members enable the 
creation, deletion, and configuration of 
"Notifier Objects" (NO) that may be 
programmed to trigger on the occurrence of 

15 any one of a defined set of VCO events. When 

a Notifier Object triggers, it make a 
function call to a special member function of 
a specified object, and thereupon conveys 
information concerning the event that 

20 occurred. 

• Configuration/ System Setup Control Members 
enable VCO configuration information to be 
saved to, or retrieved from backing store. 

• Terminal Services Control Members enable 
25 writes of text messages to VCO terminal 

output port, and command input through the 
VCO terminal input port. They also allow the 
VCO terminal output port to be attached to 
various output devices. 
30 • Network Session Control Members enable 

establishment of a network session with a 
remote station. They include members to 
invoke initialization and shutdown of the 
physical device control sub-system, as well 
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as to place point-to-point and multipoint 
calls. 

• Audiovisual/Data Signal Switching Members 
enable signals to/ from the remote station, 
and to/from transducers to be manipulated, 
combined, and interconnected in various 
combinations. 

• Binary Data Object Exchange Control Members 
enable buffers, files, and other binary data 
entities to be transferred between the local 
and remote stations. 

• System Information Store/Retrieve Control 
Members enable access to VCO parameter blocks 
containing information about their 
encapsulated devices, ctirrent call states, 
protocol states, configuration, and 
control /monitoring context. 

• Protocol Management Control Members enable 
direct manipulation of the H.320 protocol 
whose implementation is integral to the VCO. 
Allows advanced operators to perform mid- 
level operations to configure the VCO, and 
any connected remote station, according to 
the procedures of H.320. 



25 Notification Controller 

This notification mechanism is used both 
internally by the vco, and by client applications that 
wish to monitor, or respond to specific system events. A 
Notifier Object is created, and programmed to respond to 
30 any subset of the cataloged VCO events. If the event 

occurs, a special notification member in a target object 
is called and passed information regarding the occurrence 
of the event. The Notification Controller refers to all 
of the member functions and member data necessary to 
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implement the notification mechanism in each VCO. It 
contains three distinct parts that operate both 
independently and together^ depending on the notification 
task at hand. 
5 • Hotiflcation Triggering Meohaalsm is 

responsible for determining exactly when a 
Notifier Object should trigger, by examining 
its list of triggering events when one such 
event occurs. If the Notifier Object is set 
10 to trigger on the event, it is activated to 

initiate its trigger sequence, thereupon 
informing a specified software object that 
the event has occurred; it passes parameters 
during a call to a notification member 
15 function . 

• Notifier Object List Manager is responsible 
for creating, deleting, modifying, and 
querying a database containing all Notifier 
Objects for the VCO. 
20 • Linked Notifier Object List is a doubly 

linked list of all Notifier Objects for a 
VCO, and it is maintained by the Notifier 
Object List Manager. 

Terminal stream Controller 

25 This terminal stream mechanism is used both 

internally by the VCO, and by client applications that 
wish to direct streams of text messages to a configurable 
set of terminal output port destinations that may include 
files and system character devices. Alternately, streams 

30 of text messages directed to the VCO terminal input port 
are interpreted as VCO commands and invoke standard VCO 
operations. This Terminal Stream Controller refers to all 
of the member functions and mexober data necessary to 
implement the terminal stream I/O mechanism in the VCO. 
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It con-tains three distinct parts that operate both 
independently and together, depending on the terminal 
operation. 

• Termixial stream I/O Device controller is 

5 ^ responsible for processing text messages sent 

to the VCO terminal input and output ports, 
in addition to managing the list of I/O 
devices. 

• Text command Encoder/Decoder is comprised of 
10 two separate components: the encoder portion 

converts calls to the SCI into text-token 
string command representation used for remote 
VCO control, and the decoder parses an input 
stream of such text-token string commands and 
15 meUces calls to the SCI as indicated by their 

format. 

• Linked Terminal Stream I/O Device List is a 

doubly linked list of all terminal I/O device 
objects that describe the identity and status 
20 for all character stream files, and devices 

to which text messages sent to the VCO 
terminal output port are written. 

Device /Protocol Controllers 

This group of controllers serves to support the 
25 implementation of the logical operations invoked by calls 
to SCI member functions, as well as providing 
implementation of operations necessary to the 
establishment and maintenance of a connectivity session. 
The implementations of services in this VDI component 
30 must be only that portion of the given operations that 
can be supported in a fully device- independent manner. 

• Object Construction refers to all procedures 
and data structures involved in the 
construction of the VCO, including 
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init:ializa^ion of all object software 
components that do not control devices. 
Provides direct support for operations 
invoked by construction of the VCO by a 
client application. 

Object Destruction refers to all procedures 
and data structures involved in the 
destruction of the VCO, by its client 
application, including shutdown of all object 
software components* 

configuration/ System Setup refers to all 
procedures and data structures involved in 
configuring the VCO according to its profile, 
previously saved on a backing store device. 
Also includes support for specialized audio, 
video, image, and binary data equipment setup 
utilities. Provides direct support for 
operations defined for the SCI 
Configuration/ System Setup Members. 
Binary Data Object Exchange refers to all 
procedures and data structures involved in 
the transfer of named binary objects, such as 
system files, to and from the remote station. 
Provides direct support for operations 
defined for the SCI Binary Data Object 
Exchange Control Members. 

Ketvork Call State refers to all procedures 
and data structures to support a call 
controller compliant with that described in 
the section entitled Visual Call Progression, 
and consequently function to establish and 
maintain the connectivity session with the 
remote station. Provides direct support 
operations for internal VCO connectivity 
sessions. 
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System Information refers to all procedures 
and data structures involved with storage, 
retrieval, and maintenance of the various VCO 
parameter blocks, and their associated tables 
and lists. Provides direct support for 
operations defined for the SCI System 
Information Store/Retrieve Control Members. 
Capability Ezohange refers to all procedures 
and data structtires needed to support a 
structxired exchange and comparison of device 
capabilities, as described in the section 
entitled Visual Call Progression. Provides 
direct support operations for internal VCO 
connectivity sessions. 

system Exception refers to all procedures and 
data structures involved in handling fatal 
errors that may occur in the VCO. Provides 
direct support for operations defined by SCI 
VCO Settings Members not shown in the 
drawing. 

Media Control object Access refers to all 
procedures and data structures involved in 
accessing the object-based device control 
system implemented in the PDI. Provides 
direct support for operations defined for the 
SCI Audiovisual /Data Signal Switching Control 
Members (that are not shown in the drawing.) 
Protocol Mode Negotiation refers to all 
procedures and data structures involved with 
establishing a common set of parameters 
between the local and remote stations as 
described in the section entitled Visual Call 
Progression* Here also lies support for 
operations that will affect a specific 
conference profile as specified by the VCO' s 
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configuration parameters (or as set by the 
client application) ; includes support for 
operations essential to internal VCO network 
session implementation . 



5 Virtuallzation Layer 

Contains all procedures and data structures used 
to convert vendor-specific formats to those defined by 
the VCO. This layer also contains a number of controllers 
that are not always able to be implemented in a device- 
10 independent fashion, as some cognizance of vendor- 
specific peculiarities is frequently necessary to create 
a functional virtuallzation service layer. 

Event Controller 

Assigned responsibility for modulating the flow 
15 rate of device and software-generated events, in and out 
of an event queue. The queue acts a storage repository to 
record both the progress of operations carried forth by 
the VCO, as well as reports of new states and modes 
assumed by its underlying real-time device control sub- 
20 system. In general, devices and VCO controllers perform a 
mutually exclusive addition of events to an infinite 
sized event queue, in real time. A dispatcher removes 
them at a regular periodic rate, and disseminates them to 
an event processor, and to client applications desirous 
25 of knowing that one (of a particular set of events) has 
occurred • 

• Bvent Processor provides a structured 
mechanism for the VCO to respond 
appropriately to events generated by its 
30 device control sub-system. It maintains a 

number of feedback loops and procedures that 
are critical to enabling the VCO to 
adequately monitor and control its 
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connectivity session without assistance or 
monitoring by the client application. 
• Periodic Event Dispatcher checks the vco 

event queue at regular intervals to determine 
if it contains any events. If there is at 
least one event in the queue, the dispatcher 
removes it (a single event) and invokes the 
Notification Controller to trigger any 
Notifier Objects that may be configured to 
respond to that event. 

• Infinite FIFO Event Queue provides a 
sequentially-ordered cache for all events 
emanating from the device control sub-system 
or for events generated by software 
components wi«iin the VCO, It operates 
according to the first-in-first-out algorithm 
so that the original sequence at which the 
events occurred, is preserved through the 
event processing stage. Since the queue is 
constructed as a linked list of event 
records, it is capable of growing to a size 
limited only by the availability of system 
memory; thus events are never lost in any 
VMCS. 

• Critical Section Handler provides a mechanism 
to add events to the event (jueue in a 
mutually exclusive fashion. Also, various VCO 
operations that could result in resource 
contentions and deadlocks can utilize this 
component . 

Linguistic Controller 

Assigns textual labels to VCO events, states, 
operations, and a host of other functional entities, in a 
way that describes them using plain language. The role of 
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this controller is to enable VCO components to report the 
status of their operations in a readily-understandable 
format, rather than by the encoded strategies typically 
employed in computer systems. Various VCO controllers 
derive descriptive text messages from the labeling 
facilities offered here, and then send them to the VCO 
terminal output port. 

• Event Labeler Mechanism provides functions to 
return string labels for various VCO events 
of all types. In addition to returning text 
labels for the standard VCO notification 
events, this controller supports labeling for 
the generalized class of VCO events that 
includes all of the enumerated states, 
constants, modes, and string tokens 
representations of the arguments used by the 
Media Control Object Device Control 
Mechanism. The command encoder /decoder 
mechanisms also rely on the services offered 
by this component. 
• Object component Labeling Mechanism provides 
labels for VCO objects and constructs that 
are used to report the current location of 
execution, or processing, in terms of the 
names of actual VCO components invoked. 
Contains the names of the VCO classes, 
controllers, an mechanisms that are used to 
formulate precise reports for debugging, 
diagnostics, and general troubleshooting of 
VCO components. 
• Bvant and Object String Ziabal Database 

contains tables of text tokens and string 
messages accessed by the event /object 
component labeler mechanisms. 
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Device/Protocol Controllers 

The Device/Protocol Controllers for the VL and PDI 
layers, as shown in FIG. 3, represent the contribution of 
each layer in producing the virtualized multimedia 
connection services logically defined in the 
corresponding VDI controller (that occupies the same 
physical location on the drawing relative to the group of 
Device /Protocol Controllers) . This group of VL 
controllers serves to support the implementation of the 
device-independent procedures and operations supported, 
at their highest level, by the corresponding controllers 
in the VDI. As the VL controllers are specifically 
Virtualization Layer components, they serve to support 
the implementation of VDI controllers by providing any 
necessary coercion of data format, command syntax, or 
interface method, from a vendor-specific modality, to 
that defined for the VDI. In many cases, the VL supplies 
a standardized function supporting a like standardized 
VDI function, but the' embodiment of that in the VL is 
fully intended to be implementation-dependent. 

• software Coaponant Load/ initialise provides 
implementation-dependent mechanism to load 
and initialize all supporting software 
modules, libraries, and device drivers 
necessary to VCO operations. Called by VCO 
constructor, the VCO construction fails if 
all necessary components are not present or 
fail to load. No devices of any sort are 
initialized or accessed explicitly here, 
except to determine if they are installed. 

• software Component Unload/ Shutdown provides 
implementation-dependent mechanism to unload 
all supporting software modules, libraries, 
and devices drivers. Does not shut dovm 
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devices directly, but: does free all resources 
associated with VCO. 

configuration information Access provides any 
necessary mapping of configuration 
information from/ to the format used by the 
backing store method. Typically reads 
from/writes to a string-based initialization 
file and translates the string token format 
to that used by the VCO configuration 
parameters. 

Data Exchange Syntax Mapping proyides mapping 
of file and record formats to that utilized 
by the connectivity protocol stack to that 
used by the host operating system. Examples 
include conversion of buffers and files 
to/from packet formats. 

Call Event Happing provides translation of 
vendor -specific connectivity protocol stack 
representation of call and line states to 
those used by the VCO call controller, 
system Information Mapping provides 
translation of various vendor-specific 
representations of system information to/ from 
those used by the VCO, and enables 
translation of Media Control Object Device 
Control operations to H.221 device modes. 
Specific translation examples include call 
destinations, and media device states. 
Capability Mapping provides translation of 
local and remote station H.221 capabilities 
emanating from the network protocol stack to 
those used by the yco. Includes mapping of 
H.221 capabilities to Media Control Object 
capabilities. 
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system Exception Mapping provides translation 
of various fatal errors from vendor-specific 
components to standardized VCO exceptions. 
Media Device Driver Access Mapping provides 
translation of Media Control Object Device 
Control operations to Media Control Interface 
string commands that are presented to the 
Media Access Control layer. 
Protocol Mode Mapping provides mapping of 
H,221 bit-rate allocation signal (BAS Code) 
indications used by the connectivity protocol 
stack (or emulated) to the device- independent 
representation used by the VCO, 

Physical Device Interface 

Contains all procedures and data structxires used 
to interface device drivers and operating system 
resoiirces directly. All implementations of functions are 
assumed to be device-dependent, and it is the principle 
objective of this layer to locate some form of physical, 
20 or emulated support to realize those operations logically 
defined in the VDI. If the PDI cannot provide, or even 
emulate, a service specified by the VDI, then it must 
return a result code indicating that it is not capable of 
doing so. 

25 Device/Protocol Controllers 

The Device/Protocol Controllers for the PDI layer 
represent the contribution of this layer in providing the 
physical interface component of the virtualized 
multimedia connection services logically defined in the 
30 corresponding VDI controller. This group of PDI 

controllers serves as the physical implementation of the 
corresponding operations managed by controllers in the 
VL. As the PDI controllers are specifically physical 
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layer componen-ks , they support the implementation of VDI 
controllers by directly accessing device drivers and 
vendor-specific library software components provided by 
third party OEMs; in the most efficient designs^ the PDX 
5 may be implemented as an actual device driver, directly 
controlling hardware. 

• OEM Support Libraries and Drivers provide 
specialized ^functions, such as image 
processing, digital signal processing, data 

10 port interface, and system diagnostics, that 

are vendor-specific and usually hardware- 
specific. 

• configuration Information Backing Store is 

the physical device that stores the VCO 
15 configuration information. Usually a file on 

disk and/or some form of non-volatile memory 
device • 

• Connectivity Protocol Stack is the actual 
interface to the network, and includes all 

20 associated hardware and software components. 

The network service is presented to the VCO 
session components and transducers at the 
level of the OSI Transport Layer, whose 
responsibility it is to ensure reliable 

25 transfer of messages between end users. The 

Network and Data Link layers must be 
available, in some form, below the Transport 
Layer, and a physical or emulated network 
interface unit must be present and 

30 detectable . 

• Media Access Control provides physical device 
control mech€uiisms for input and output 
transducer devices in the system. This driver 
complement is used directly to implement the 

35 PDI's defined set of device control interface 
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functions used directly by the VDI, as well 
as by the Media Control Object Device Control 
Mechanism. 

• Device Capability List resides in the PDI as 
5 the master list of the all of the VCO 

capabilities* It is stored as an array of 
device-independent capability constants that 
reflect the range of H.320 (H.221) capability 
BAS codes. 

10 • Device Mode List resides in the PDI as the 

master list of the all of all possible device 
modes for any H.320 compliant station. It is 
stored as an array of device- independent 
device mode constants that reflect the range 

15 of H.320 (H.221) mode command BAS codes. 

• Media Control Objects (MCO) are constructed 
and maintained by the PDI, and presented to 
the VDI, as a method to control all signals 
to and from remote stations and transducers 

20 under VCO administration. The PDI interacts 

directly to support the device-dependent 
implementations that underlie these device- 
independent representations of 
audiovisual/data signals and devices as 

25 discreet system objects, each possessing a 

structured set of properties and well-defined 
operations. ^ 



VCO SOFTWARE ARCBITECTURE 
System Dynamics 

30 It is useful to consider the VCO as a mechanical 

device, much like a spring-driven mechanical clock 
movement. Each VCO is a self-contained machine of 
interlocking parts, with a system timer interrupt 
advancing its works by the increment and released in 
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balanced measures that bring stability and smoothness of 
operation to the system's "top" end* The VCO's analogous 
"unwinding" takes place with the literal precision of a 
clock's escapement mechanism, in that the system timer 
5 serves as the regulatory entity releasing a steady pulse 
of queue-stored activities from the device control sub- 
systems, to a client application. A Virtualized 
Multimedia Connection System presents not only an 
idealized control mechanism to applications, but also 

10 idealizes the rate and content of the system's responses 
to these controls, without ever losing a system event, 
state change, mode change, exception or interrupt 
request* The overall VCO design is consistent with that 
of multi-threaded, queue-based device driver designs that 

15 accoiint for a significant portion of the dramatic gains 
in reliability and performance seen in the use of 32-bit, 
multi-tasking operating systems such as IBM's Operating 
System/ 2 (see H.M. Deitel, M.S, Kogan, The Design of 
OS/2, Reading, Massachuetts, Addison-Wesley, 1992). 

20 Notes On Drawing 

FIG. 4 depicts an a detailed diagram of the major 
components and control flows of the Virtual Connection 
Object software architecture. The Device/Protocol 
Controllers shown are the same as those shown in FIG. 3, 

25 but the purpose in this drawing is to illustrate the 
direction of control flow through them, rather than to 
describe what they are. This discussion will examine the 
VCO in terms of its specific software mechanisms. To 
clearly show the functionality of individual VCO 

30 components in the two-dimensional drawing, it is 

necessary to alter their exact locations in the layering 
model from a perfect vertical orientation, to one more 
suited to revealing component interactive pathways. 
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Summary of VCO Software Arebltecture 

The software architecture of the VCO is can be 
described best in terms of two major functions: (a) 
controlling the multimedia connectivity sub-system it 
5 encapsulates, and (b) responding to events emanating from 
it. What ensues is a brief overview of outstanding 
features that characterize the dynamics of the VCO 
software model. 

• The Software Control Interface (SCI) contains 
public member functions that enable a client 
application to access a consistent and 
logically-defined multimedia connectivity 
service to create a live audiovisual 
connections to a remote station. Calls to 

15 these members invoke the various 

Device/Protocol Controller services in the 
various VCO layers until some physical 
operation is eventually performed, the result 
of which is translated to logical, 

20 standardized result prior to being returned 

to the caller. 

• Each VCO contains a general repository for 
all system information that is continuously 
updated to reflect the current states of all 

25 controllers and devices. 

• Every VCO has standard input and output 
terminal ports that function much like the 
standard input and output devices in 
operating system shell console devices. All 

30 text message sent to the VCO terminal output 

port are written to a list of terminal I/O 
devices maintained by a Terminal Stream 
Controller. This controller also accepts text 
commands written to the terminal input port 

35 and decodes them, translating them to SCI 



calls* An infinit:e FIFO event queue accepts 
the addition of events asynchronously, in 
real-time, by device control software, and by 
software components in the VCO that generate 
their own particular events. 

An Event Dispatcher runs synchronous with the 
operating system scheduler (does not preempt 
the regularly scheduled time slices) to 
remove events from the queue at a constant, 
periodic interval and disperse them to a 
Notification Controller. 

The Notification Controller examines the 
dispatched event, dispensing notification 
information about the event via Notifier 
Objects that send the indication, and all 
associated information, to an event processor 
in the VCO (if the event is from a device), 
or to a client application object, depending 
on the Notifier Object's configured 
destination object. 

The VCO Device Event Processor invoices 
procedures to respond appropriately to events 
emanating from the device control sub-system, 
so as to maintain a connectivity session with 
the connected remote station. Call control, 
capability exchange, and various protocol 
operations are driven by the event processor, 
as is the issuance of text messages, 
describing all system activities, to the 
terminal output port. Most network events 
that require attention from the application 
in similar multimedia connection systems do 
not require such attention by VCO Clients; 
specific intelligences in the Device Event 
Processor component better direct them to 
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invocation of specialized internal procedures 
ladre suitable to such tasks, by their very 
designs — feedback loops often found in the 
application layer, reside in the VCO proper, 
alleviating the application developer from 
implementing sensitive protocol-specific 
modules. 

Ubiquitous throughout the VCO's controllers 
are reporting mechanisms that formulate 
detailed text messages describing the current 
state, mode, process, subroutine, class name, 
or event that is currently most relevant, and 
sending this string to the terminal output 
port. An Event and Object Labeler working in 
conjunction with a string database, has- 
feattires that can assign text: names and 
terms, in addition to maintaining a text- 
token definition of the VCO text command set. 
VCOs can link together across a connection to 
control or monitor the activities of the 
other station. This concept, referred to as 
attachment, utilizes a bi-directional text 
message stream to enable interconnected VCOs 
to share commands and events. Depending on 
the negotiated configurations of the 
"attached** VCOs, calls to member functions in 
the SCI of one, are encoded into text 
commands by the Command Message Encoder, and 
transmitted to the other station. Upon 
receipt, the Command Message Decoder 
translates the text commands back to SCI 
calls. Correspondingly, events queued at one 
station, as well as results of operations, 
are encoded by the Event Message Encoder, and 
transmitted to the other station. Upon 
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receipt, the Event Message Decoder translates 
the text event messages back to events and 
adds them to the event queue, where they are 
dispatched along with a station identifier. 

5 Software Control interface 

The Software Control Interface (SCI) consists of 
the VCO's piiblic member functions and protected data that 
allow client applications to control the VCO. Any request 
for service using the SCI must pass a number rigorous 

10 examinations designed to reject any possibility of 

damaging the encapsulated sub-system. A client attempt to 
access a VCO member function results in an immediate set 
of verifications to determine if VCO is available for 
use, and if so, whether the context of the request is 

15 valid. For example, most operations rec[uire that the 
device control sub*system first be fully initialized. 
Arguments are checked for validity, and a text message 
describing the request is sent to the VCO terminal output 
port for tracing and monitoring purposes. If all 

20 conditions have been met, execution continues to the next 
level; progressing typically to a further request to the 
PDI. Rejected requests are turned away abruptly, but the 
client is compensated for his diligence, with a fair 
accounting of the dismissal; every operation returns a 

25 concise result code. 

Member Functions 

Member functions to invoke the services of the VCO 
are partitioned into several distinct categories. The 
members and their arguments are highly structured and 
30 flexible in the variety of ways they may be utilized. 
They are easily mapped to a text-token command set. All 
of the members of this interface are available from one 
constructed VCO, and each optimized to best support the 
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likely use of it, rather than providing similar access 
methods for all command permutations equally. The 
pathways through the VCO layers and components are unique 
for each functional group, and are siommarized briefly: 
5 • Event Notification Control Members make calls 

to the Notifier Object List Manager to 
create, delete, and configure, and trigger 
Notifier Objects in the Linked Notifier 
Object List. Calls to trigger notification 
10 invoke the Notification Triggering Mechanism 

directly. 

• Terminal Service Control Members make calls 
to the Terminal Stream I/O Device Controller 
to add and remote devices from the Linked 

15 Terminal Stream I/O Device Listi Calls to 

send text messages to the terminal output 
port are made through this object, as are 
calls to send text command message to the 
t:erminal input port for decoding and 

20 execution. 

• Configuration/system setup control Members 
make calls to the PDI to store and retrieve 
configuration information from some physical 
backing store device. 

25 • Network Session Control Members make calls to 

the PDI to initialize and shutdown the 
encapsulated multimedia connectivity sub- 
system, as well as to initiate and terminate 
sessions with a remote station. 

30 • Audiovisual/Data Signal switching Control 

Members make calls to the PDI to manipulate 
audio, video, image, and data objects that 
comprise the Media Control Object Device 
Control System of the VCO. 
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e Binary Data Object Exchange Control Members 

make calls to the PDI to transfer binary data 
objects and data buffers to and from the 
remote station. 
5 • System information Store /Retrieve Control 

Members make calls that access the VCO system 
information repository in a structured 
manner; a manner which does not allow for any 
direct modification of VCO data structures, 
10 • Protocol Management Control Members make 

calls to the PDI to directly set H.230 device 
modes, send capabilities to the remote 
station, and perform other protocol related 
tasks. 



15 rrerminal service 

The VCO terminal service has two main pathways: 
into the VCO through the terminal input port, and out of 
the VCO through the terminal output port. Alternately, 
when the terminal ports are considered as standard input 
20 and standard output devices for the VCO, it is sensible 
to view the two modalities as a stream "to the tenainal" 
and "from the terminal". 

• Output Streams to vco Terminal originate from 
the vco itself, or from client applications. 

25 Messages "to the terminal" are directed to 

the terminal output port and dispersed, via 
write operations, to output devices (attached 
to the terminal output port). Siammary, "To 
terminal" is synonymous with "to text output 

30 devices." 

• Input Streams from VCO Terminal originate 
from outside the VCO, typically from a dumb 
terminal or client application wishing to 
control it with text commands. SCI calls 
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sending text: messages as if "from the 
terminal" are directed to the terminal input 
port and interpreted as input text command 
messages, as if input from a keyboard. 
5 Summarily, "From terminal" is synonymous with 

■from the standard text input device." 

• Terminal Stream I/O Device Controller 
maintains a linked object list of output 
device objects to which the text message sent 

10 to the terminal output port are written. All 

text messages sent to the terminal output 
port are written to every device cataloged by 
the linked object list, output devices 
include system files, character devices, and 

15 Notifier Objects created for the transmission 

of text message to objects. 

System Information Handling 

System information is fully protected from direct 
external access the VCO, though all internal components 
20 can access it directly. Clients must us specific member 
functions to get a copy of the data, and use other 
members to affect changes to it through structured 
operations. Internally, all system parameters are fully 
accessible to all components derived from the VDI. 
25 • configuration Parameters store the current 

copy of VCO configuration and system setup 
information that is read from backing store 
at VCO construction time. Contains 
information about the network service 
30 available, and all system defaults. The 

parameters can be modified and written back 
to backing store at any time. 

• Device Parameters store all settings and 
parameters related to the 
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audio/ video/ image/data devices installed in 
the sub-system, and retain handles to the 
current source, destination, input, and 
output signals affected by the Media Control 
5 Object Device Mechanism. 

• Call Parameters store all of the current call 
and line states, including those for 
multipoint calls. Maintains records about 
other stations in the conference. 

10 • Protocol Parameters store all current 

transmit and receive modes for all the 
various data types. 

• Control Prametera stores all information 
related to maintaining the remote station 

15 control mechanism for any attached station. 

• Monitor Parameters store all inforittation 
related to maintaining the monitoring access 
for any attached station. 

Notification Mechanism 

20 The VCD notification mechanism conveys an 

indication that a particular event has occurred by 
activating, or "triggering", a notification entity 
referred to as a Notifier. Maintained in a list internal 
to the VCO, Notifier Objects are created specifically to 

25 call a member function of some appropriately enhanced 
class object, somewhere in the system (within or without 
the address space of the VCO) when triggered. Upon the 
VCO event dispatcher's presentation of an event to the 
Notification Controller, Notifier Objects in the list are 

30 systematically examined, and potentially triggered, 

according to a specialized modality of governance that 
considers the relationship of the outstanding event type 
(among other parameters) to the triggering profile of the 
Notifier Object itself. 
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Notifler Objects (HO) 

These objects comprise the basic indication unit 
of the VCD notification mechanism. Each NO is an instance 
of a class object that may be created by a VCO client, or 
5 the VCO itself, and configured to "trigger" in response 
to the occxirrence of any one of a set of VCO events . Each 
NO is associated with a specified Notification Receiver 
Object (NRO) to which the trigger response is directed. 
When an NO triggers, it makes a function call to the 

10 associated NRO meiaber function assigned to the task of 
handling notifications. Passed to the NRO is an event 
identifier, and a number of qualifying argriments that 
describe the context of the event's occurrence. There are 
two mutually exclusive modalities for any NO; they can be 

15 configured to respond to any event, or configured to 
respond only to events emanating from VCO-encapsulated 
devices • 

Notifler Management 

This task is handled by the Notifier Object list 
20 handler. This component adds to, removes from, and 
maintains the integrity of the Notifier list. It also 
provides members for configuring Notifier Objects with 
new trigger response profiles, as well as to allow them 
to be enabled, disabled, and examined for statistical 
25 information. In the VCO, the notification mechanism is 
supported by a component that manages the list of all 
active Notifier Objects, and a triggering mechanism that 
determines as to whether or not an individual Notifier 
should trigger, based upon the occurrence of an event to 
30 which it is configured to respond. 

Triggering Mechanism for Notifier objects 

This mechanism conditionally determines as to 
whether or not a Notifier Object should trigger, based 
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upon a specific algorithm. Notifier Objects can be 
configured to respond to events that emanate from the 
device only, so as to direct their trigger response to 
the VCO Device Event Processor. Through this method, the 
5 VCO uses Notifier Objects internally to create a direct 
pathway for device events (added to the VCO queue by the 
device) , to be processed in the VCO Device Event 
Processor exclusively. This distinction serves to prevent 
an infinite loop that would result if the VCO processes 

10 an event from a device, and then reissues (requeues it) 
it so that client applications can be subsequently 
notified of the same event — the same event would be 
dispatched back to the event processor again and again if 
reinterpreted as another occurrence of the same device 

15 event. Thus a distinction must be made between the 

original device event and a processed derivative of that 
same event intended for dispatch to the client 
application. Notifier Objects configured to trigger on 
events directly from devices will only trigger on events 

20 directly from devices. When the event processor reissues 
the event from the device, it marks it to indicate it is 
not directly from a device, and it can no longer trigger 
the Notifier that would send it to the Device Event 
Processor. 

25 Notification to Clients 

VCO Client applications may request notification 
of a combination of VCO events by creating a Notifier 
Object and configuring it to trigger when any single 
event in the combination actually occurs. Once created, 
30 the Notifier Object conveys event notification to an 

application object set to that purpose. The object that 
receives notification is referred to as a Notification 
Receiver Object (NRO) . 
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Notification Receiver Objects (NRO) receive 
fxinction calls from an entity in the VCO that 
is created specifically to direct 
notification of the occurrence of an event to 
them. A class object can serve as an NRO if 
it contains a special Notification Receiver 
Member and an attendant thunk . The thunk is a 
globally accessible function that is created 
to receive notification from the VCO and 
redirect that notification to the NRO's 
Notification Receiver Member. In this way, a 
VCO can deliver a notification message to a 
class object which can then directly access 
other class members and member data that 
would not be available if the notification 
was to a non-member function i.e. had to 
access class members with a special class 
pointer . 

Notif ier Triggering Profiles refer to the set 
of events to which the Not if ier Object is 
configured to respond. Not if ier Objects are 
"triggered" to notify their associated NRO 
when one of these configured events occurs. 



Even t , H a n dling Mechanism 

25 The event handling mechanism consists of three 

concurrent^ but distinctly separate processes. From the 
perspective of any single event, these processes occur in 
a serial fashion. First, events are added to the trail of 
the VCO event queue by various VCO components. Next, a 

30 concurrently executing event dispatching process 

periodically removes an event from the queue. Finally, 
the event dispatcher sends the removed event to the 
Notification Controller where it triggers Notif ier 
Objects configured to respond to events of this 
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particular type. If the event is a device event, and the 
Notifier is configured to respond to device events, then 
its Notification Receiver Object receives notification 
that the event has occurred. If the event removed by the 
5 dispatcher is some derived event, it may trigger 
notifications to client application, or any other 
Notification Receiver Objects targeted by a Notifier 
responding to that event;: 

Device Events 

10 These events are generated directly by a device in 

the encapsulated sub-system; a situation that potentially 
requires some kind of immediate responsive action* They 
are the primary responses from VCO devices and emanate 
from network and media control driver software 

15 components. 

Derived Events 

These events are generated by a VCO software 
component, and are derived from an action or logical 
state, not directly emanating from a device* They are the 
20 secondary responses from the VCO itself, often resulting 
from the processing of device events. 

Event Processing 

The task of event processing includes the handling 
of both Device Events and Derived Events. Device events 

25 can only trigger Notifier Objects configured to respond 
to device events, thereby enabling a particular Notifier 
Object to function as a dedicated device event notifier. 
Events entering the Device Event Processor are typically 
line state changes, device mode changes, and indications 

30 from the remote station. These events drive protocol and 
session management routines during processing, which in 
turn generates derived events such as the call state 
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changes and Media Control Object Device Control pareuneter 
changes. These derived events are queued for sxibseguent 
dispatching to client applications; these secondary 
occurrences are treated differently from primary events 
5 in that they will not be handled by the Device Event 
Processor. 

Event Dispatching 

Dispatching of events occurs periodically at a 
programmed rate that may be adjusted dynamically at run- 

10 time. Typically, dispatching five events per second is 
sufficient to present the client application with a 
manageable stream of events. The event dispatcher is 
driven by a system timer interrupt. If the queue is 
available for mutually exclusive access, it is checked to 

15 determine if there are events in it. If there is at least 
one event in the queue, one event is removed in a 
critical section, and the queue is released to the 
system. If mutually exclusive access is not immediately 
availfiJDle, or there are no events in the queue, the 

20 dispatcher yields. Otherwise, the removed event is next 
presented to the Notification Controller where any 
Notifier Objects in its list, sensitive to the event, are 
triggered so as to disperse the event throughout the 
system 

2 5 Event Queuing 

Queuing of events occurs sporadically, when an 
event is generated by a VCO-encapsulated software or 
hardware component. Frequently occurring during hardware 
interrupt cycles, cpieuing is carefully optimized to 
30 require very few cycles and little resource allocations. 
A short blocking operation may be necessary during 
dispatching to gain mutually exclusive access to it» The 
event is added and the queue released back to the system. 
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If the atterpt to add an event to the queue fails, a 
fatal error (VCO Exception) occurs and the VCO is 
permanently disabled. 

Exeeption Handling Matters Meehanisa 

5 The VCO exception handling mechanism is not shown 

in FIG. 4. Exceptions in the VCO are conditions that are 
deemed fatal errors from which the system cannot recover 
v'ithout risking a system crash. The underlying design 
principle to VCO exception handling is that system 
10 crashes result most often from continued use of a 

destabilized system component, from attempts to recover 
from destabilized conditions, and from the failure of a 
destabilized system to acknowledge its ••time-bomb" 
status. In accordance with an overriding concern for 
15 system reliability, VCO exceptions generate reports, and 
a subsequent disabling of the VCO. Neither the VCO, nor 
its concomitant support software, is accessed until the 
VCO is destructed. Once disabled, all calls to the SCI 
return immediately with a result code indicating that the 
20 VCO has been disabled. For continuous use applications, 
the risk of system crash is rendered unlikely, and the 
system witti one destabilized sub-system likely remains of 
S.\l££icient health to invoke a resident backup system. 

Fatal errors occxirring internally to the VCO 
25 generate an internal assertion failure that invoke a 

recovery routine that proceeds to execute a reverse stack 
trace. The trace searches for markers pushed onto the VCO 
stack during calls to a special member function called 
upon entry into the VCO. Every VCO entry point is guarded 
30 by a call to a function that returns a result code 

indicating whether or not the VCO is enabled or disabled. 
Upon locating the address of the instruction pointer (on 
the stack) at the execution point of this status call, a 
result code indicating that the VCO is disabled is pushed 
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on-bo 'the s^ack, along with tihe address of Uie exi'bry 
point. A return instruction is executed to bring the 
calling thread back to its original point of execution 
just prior to calling the VCO status mexaber (which will 
5 indicate that the VCO is "unavailable* when the status 
call is re-executed) , and to the impression that it has 
been turned back at the door due to a preexisting 
disabled state. The calling thread is without cognizance 
of the fatal error it unwittingly generated by its 

10 venture inside the VCO, and finds the VCO is simply 

unavailable for continued use« This technique of shutting 
down the damaged VCO, accompanied by transparent error 
handling (from the perspective of invoking applications) , 
maintains system integrity until the host system can risk 

15 a recovery operation. 

Exception Handler Modalities 



invoked incrementally by specifying any combination of 
the following modality flags. These modalities are 
20 additive, and affect the way in which reporting of the 



A variety of VCO exception handling modes can be 



exception is handled. 



25 



30 



Debug modality flag, if set, specifies that 
detailed debugging information (in a message 
box) will be displayed at the time of 
exception. This mode is intended for use 
during system development where proprietary 
information will be displayed* 
User modality flag, if set, specifies that 
general "user" information (in a message box) 
will be displayed at the time of exception. 
This mode is intended for use in the field 
after the product is released. 
Term modality flag, if set, specifies that 
exception information will be sent to the VCO 



PCT/US97/15018 

- 77 - 

terminal output port for display on terminal 
output devices. 

Notify modality flag, if set, specifies that 
the exception will generate an exception 
event and trigger Notifier Objects prior to 
disabling of VCO. 

Abort modality flag, if set, specifies that 
the exception will abort all VCO operations, 
after reporting the exception, and disable 
the VCO. 

Event and Object Labeling Mechanism 

This mechanism provides function calls that 
convert indexes to strings. It relies on a collection of 
string tables, whose string element positions reflect the 
15 value of the indexes. The string tables can be loaded 

from resource files that contain text in the appropriate 
language • 

Labeling of Events, Enumerated Values and Result codes 

Retrieving a text label to describe a VCO event Is 
20 accomplished by presenting a VCO event identifier, result 
code, or standard enumerated constant to the appropriate 
member function. A pointer to a static copy of a null 
terminated label is returned, and is typically used to 
formulate messages for terminal output, and by 
25 applications to display states, modes, and operations 
taking place In the VCO. 
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Labeling Objects 

Retrieving a text label for a VCO software object 
is accomplished by presenting a pointer to the object to 
30 a member function. A pointer to a static copy of a null 
terminated label is returned, and Is typically used to 
formulate messages for debugger and trace window output* 
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Used specifically for debugging, diagnostics, and 
troubleshooting • 

Event and Object String Label Database 

s A memory resident database in the VCO contains 

tables of string records for all of the VCO enumerated 
constants, and the VCO command set. Reference databases 
containing object pointers and labels are created at VCO 
construction time. 

10 Media Control Object Device Control Meehaniam 

Designed to facilitate the manipulation of signals 
as distinct objects, this device control method is 
intended for full implementation as a graphical desktop 
media control system, supporting a drag and drop signal 

15 switching model. Each object, representing a specific 
signal type, has a standardized set of properties, and 
well-defined modes of interaction. The physical structure 
of the Media Control Object Device Control Mechanism 
represents each signal as a software class object, and 

20 all signals currently available in the system as a linked 
list of such objects in the VCO DEVICEPARAM structure. 
Media Control Objects are created and deleted as signals 
become available, or unavailable, depending on connection 
state and device availability. 

25 VCO signals are identified according to their type 

and direction. The possible types of signals include 
audio, video, image, and binary data. The possible 
directions include input from the remote station, output 
to the remote station, input from a local transducer, and 

30 output to a local transducer. Member data in each Media 
Control Object describe the current states and modes 
related to the signal. Member data in each Media Control 
Object describe the current states and modes related to 
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t:he signal, and member functions invoke physical 
operations in their host devices. 

It is possible to determine if a given Media 
Control Object is capable of specific operation by 
5 setting the query flag on the SCI member function to 
control them. In this manner, the client can test an 
operation without invoking it. A special function to 
return the capabilities of a setting is also available, 
and a list of settings constants (or parameters for the 

10 setting) is returned. For H.221 capabilities, related to 
the multimedia interconnection protocol, the VCO 
parameter block maintains an updated listing. There is a 
very close logical mapping between H.221 capabilities and 
Media Control Object capabilities — no H.221 video mode 

15 means that there is no motion-video available — and it 
is likely that the very existence of a Media Control 
Object indicates that most of the operations for that 
signal type are supported to some degree. It is often 
sufficient to let a client attempt to set the mode, and 

20 report that the system is incapable, than to constantly 
monitor and maintain a local capability listing. 

Device/Protocol Controllars 

The divers Device/ Protocol Controllers, discussed 
in the overview section, each have emulation components, 

25 shown in FIG. 4, that reside in either /both the VL and 
the PDI. The objective in any VCO emulation mode is to 
enable to the VDI to operate fully, without the ability 
of it, or any client applications, to differentiate 
between operation with actual device support, or 

30 emulation of it. There is an emulation mode flag in the 
system information that determines the operating mode. 
Any operations supported in the VL or the PDI must check 
this flag during every invocation of service, and either 
access a physical device, or provide a set of results 
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indistinguishable from having done so. No support for 
emulation of operations exists in the VDI ~ it makes no 
direct references to low- level device services except 
through the PDI. 

5 Remote Station Attaohaent Mechanism 

Attachment of a remote station to the local 
station enables the local station to monitor its event 
stream and control its operations. The basic mechanism of 
attachment has been discussed in general, however the 
specifics of this interaction deserve more attention. 
Essentially, an attachment mechanism sufficient to 
monitor a remote station requires a cross -linking of the 
output of one station's event encoder to the other 
station's event decoder. To establish control of a remote 
station, there must, in addition, be a cross-linking of 
the output of one station's command encoder to the other 
station's command decoder. There are a number of 
operational considerations that become the subject of 
negotiation between the stations, once attachment is 
accomp 1 ished . 

Monitor context 

Monitoring context refers to the station that is 
the source of the current event stream emanating from the 
local VCO's dispatcher. Any combination of the monitoring 
modes can be in effect once attached, a VCO that is not 
attached to a remote station can only monitor local 
events. The remote station must grant permission to be 
monitored by the local station by indicating so in its 
monitor parameters, vco monitoring modes are described as 
follows: 

• Local monitoring mode affects the target VCO 
to dispatch and process events local to it. 
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• Ramote monitoring mode affects the target VCO 
to dispatch and process events emanating from 
the remote station to which it is currently 
attached. 

5 • Array monitoring mode affects the target VCO 

to dispatch and process events from a 
specified array of remote stations. 

control Context 

Control context refer to the station that is 
10 controlled by calls to local VCO SCI member fiihctions. 

The remote station must grant permission to be controlled 
by the local station by indicating so in its control 
parameters. VCO control modes, from the perspective of 
the local station, and when set in the physical local 
15 station VCO, are described as follows: 

• Master control mode enables the local station 
to control a remote station to which it is 
currently attached. 

• Slave control mode enables the local station 
20 to be controlled by a remote station to which 

it is currently attached. 

• Peer control mode enables both the local and 
remote stations (attached to each other) to 
control themselves, but not each other. This 

25 is the standard operating mode for most 

interconnections between stations. 

CIiJENT SOFTWARE ARCHZTECTURB 

FIG. 5 depicts a VCO client application; arrows 
highlight the flow of function calls through its various 
30 components. The diagram shows a full implementation of a 
VCO client application that best describes the VCO Client 
application concept. All of the components shown are not 
necessary to establish a minimally-functional multimedia 
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connectivity session with a remote station, but are 
needed to make full use of the entire VCO feature 
complement. The client application specification, unlike 
that for the VCO itself, is represented in a generalized 
5 fashion, and strict compliance is not necessary to 

achieve the benefits touted by the VMCS; a broad range of 
effective application designs may be derived from this 
prototypical VCO Client application model illustrated. 

Summary of Client softvare Architecture 

10 A client application selects a class library 

supporting an implementation of class VCO. Constructing 
class VCO, it makes calls to the Software Control 
Interface for the newly invoked VCO to establish a 
connectivity session with a remote host. The client has a 

15 ntaaber of components that it uses to manage this session: 

• ThB DBvice-xndependent Connectivity 
Application Shell provides the user- inter face 
and basic task management for the client 
application. This component displays session 

20 status information, and initiates the 

milestones of its inception and termination. 
This component is the logical control 
mechanism for all VCO operations, if it is to 
construct a VCO directly, it must be created 

25 with the same object-oriented language as the 

VCO itself. While it is preferred that the 
client is a GUI application to best present 
the VCO control system to the user, it can be 
as simple as a daemon running in background, 
that processes string commands from a data 
stream directed to it. 

• A number of Notification Receiver Objects 
receive notifications from the VCO that 
various VCO events have occurred. Client 



applications typically create a Notifier 
Object to receive text streams from the VCO 
terminal output port* At least one other 
Notifier Object should be created to receive 
indication of the three major classes of new 
local station modes (new H.221 transmit 
modes), new remote station modes (new H.221 
receive modes) , and new call state changes 
(new call and line states) — one Notifier 
Object can be configured to respond to all 
three of these event types. 
Ev&nt SLTid TBxt ProcBssing Components are 
specifically designed to analyze and/or 
respond to text and event information 
emanating from the VCO. Text processing of 
the terminal output stream can take the form 
of graphical display in a trace window that 
has the facility to enable its viewer to move 
forward and backward through the output 
messages^ in order to view the progress of 
the session. Trace information could also be 
saved to a log file to permit later analysis 
of session activity. Finally, trace output 
can be analyzed by a debugger, or H.320 
protocol analyzer. New remote station modes 
are usually routed to the Station Profile 
Controller for processing and interpretation. 
The Station Profile Controller examines new 
modes set by the remote station, and using a 
station Profiler, compares them to a 
database, to determine the remote station's 
manuf actiirer or type. Once identified, the 
remote station's profile is elicited from 
that same database, and its non-standard 
feature set made available to the 
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application. Non-standard features include 
advanced camera control operations, 
proprietary VCO features^ data exchange 
protocols, and application sharing features. 
5 Non-standard capabilities are also examined 

to determine the level of functionality, of 
which the remote station is capable. The Non- 
standard H.221 Mode Mapper provides a 
virtualized representation of the remote- 
10 station's available special features, and 

presents them to the application shell in a 
manner conducive to their mapping to local 
station physical controls. 

Application Notification 

" In the general sense, a stream of events flows 

from the VCO to the client* Ongoing notification of the 
application, by the VCO, in the form of multiple 
concurrent event streams delivered to application class 
objects, changes the context of the VCO from a sub-system 

20 invoked by the client, that returns values in response to 
commands, to an adjunct connectivity operating system; an 
operating system running in parallel with the primary 
operating system, actively communicating with its client 
application processes through an interrupt -like 

25 mechanism, and similarly operating completely 

independently to specifically manage system multimedia 
connectivity resources. 

Notifications from the VCO, to its client 
applications, take place using a mechanism designed to 

30 provide structured entry points that function much like 
interrupt service routines. Prom the perspective of the 
client, the design eliminates the risk of interfering 
with the delicate timing of the underlying multimedia 
connectivity sub-system, and does not confound normal 
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t.±ja& slice allocations by the operating system scheduler. 
At the level of the application, notifications are 
discreet entities that are independent of any operating 
system or GUI event processing/queuing schemes, and 
5 resultantly more time-responsive; so much more responsive 
than adding events added to the application event queue, 
that notifications can preempt drawing operations by the 
GUI, but without inordinately starving the GUI of its 
time slices. The notification is usually implemented to 

10 run on a separate thread, concurrent with those drawing 
on the display, and thus connectivity events can be 
processed concurrent with drawing, rather than subsequent 
to a GUI operation in progress. The VCO Client 
notification system permits the design of high- 

15 performance, multithreaded applications that can process 
and respond to connectivity events with responsiveness 
that (in the context of a user interface) approximates 
real-time. Notification to VCO client applications, 
proceeds with rapidity such as is required for 

20 controlling both local peripheral devices, and the 
peripheral control features of remote stations, while 
concurrently maintaining a responsive graphical desktop 
display. 

Notification Reoeiver objects 

25 In the application, any class object can be 

configured to receive calls from a Notifier Object when 
any one of a subset of events occurs. A member function 
in the object is declared for this purpose by the 
creation of a thunk. As previously described, thunks are 

30 created to redirect calls from the Notifier Object in the 
VCO, from a public global non-member function in the 
application (called by the Notifier Object) , to the 
particular class object instance and member function 
intended exclusively for the purpose of notification. The 
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receipt of notifications by the application often results 
in the application's issuance of calls back to the VCO to 
correct, compensate, or respond to the condition. Many 
event handlers in the application function as feedback 
5 loops; upon notification, they immediately invoke VCO 
functions in response. Logical assistance by the client 
application is unnecessary once appropriate response 
routines have been setup - the VCO manages the multimedia 
connectivity system automatically, 

10 Station Profiling 

The primary objective of the client station 
profiling mechanism is to first identify the remote 
station as one represented in a local database of 
potential remote station types. Once a descriptor for the 

IS remote station is found in the database, the client can 
now determine any non-standard device modes (that invoke 
special features) supported by that remote station. 
Further, a list of corresponding non-standard 
capabilities is also stored in the descriptor, such that 

20 the local station can make a positive predetermination as 
to whether the special feature associated with the remote 
station type, is actually available for use. Nonstandard 
modes supported by the remote station can then be mapped 
to loeai-controls so that the VCO client becomes capable 

25 of a degree of station control typically only possible by 
interconnection between two stations from the same 
manufactxirer - VCO stations can fully understand the 
particular proprietary non-standard features they 
support. The VCO client is capable of an extraordinary 

30 degree of compatibility with an unlimited range of remote 
stations . 
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Station Profile Controller 

This software controller contains three components 
that provide the functions necessary to implement a 
transparent mapping between local station controls, and 
5 remote station non-standard features. Local station 
features, beyond those represented in the VCO control 
mechanism have specific sequences of device modes that 
must be set to activate them. Non-standard modes on the 
remote station work the same way, except the mode 
10 sequences are different. The three components of the 

Station Profile Controller enable the client to associate 
any local or remote station non-standard feature (mode 
sequence) with a control on the local station. In short, 
the Station Profile Controller offers a symbolic, device- 
15 independent representation of local and remote station 
non-standard features, and beyond that, the ability to 
associate one local with one remote. An example of this 
association is in order: consider a surveillance system 
that maintains two specialized features: 
20 1) It allows an operator to remotely select the 

current camera from a variety of available 
input cameras. 
2) It displays an "X" cursor on the operator 
station video image, pinpointing the exact 
25 center of focus for its currently selected 

camera, and the remote station will move its 
selected camera to correspond to any mouse- , 
invoked change in the cursor location on the 
operation display, therein allowing the 
30 remote operator to survey the area with 

simple mouse movements. The remote station 
will continuously reflect the camera's actual 
physical position by rendering a cursor on 
the operator station visual display. There 
35 is no H.320 representation of these 



PCTAJS97/15018 



- 88 - 

opera'tions, beyond support for sharing a 
ciirsor position; the selection of a remote 
camera is a simple operation, but the second 
feature is one complex, proprietary, and in 
need of specialized library support featiures 
— the cursor movement mechanism requires a 
complex feedback mechanism to move and 
display the "X" cursor as intended by the 
remote station's programming. When the 
operator station connects to this monitor 
station, the operator station determines that 
the remote station is of this particular 
monitoring station type, and locates a 
descriptor in its database that describes it* 
The modes to select the camera are 
represented symbolically to the VCO client, 
and mapped to local station controls. The 
sequence of mode*setting operations necessary 
to the selection of the remote station camera 
is invoked by offering the symbolic 
representation of the operation to the 
Station Profile Controller* For the more 
complex cursor-aiming feature, incoming 
ciirsor position modes are mapped to a 
virtualized definition of cursor movement, 
and passed to functions in a library of 
supporting routines, developed specifically 
to display it as reqpiired. Local station 
mouse movements over the video display 
region, on the operator station's bitmapped 
display, are mapped to cursor movements sent 
to the remote station via a similar mechanism 
used for camera selection. It is the VCO's 
notification mechanism that enables the 
concurrent processing of device modes. 
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sending and receiving 'them lio/from -the remo1:e 
station , at the system level of the GUI 
application, without interference from other 
application activities. 

5 Station Profiler 

This component is responsible for identifying the 
remote station. Upon connection, it sets sequences of 
modes, and conducts whatever query is necessary to 
determine its manufacturer. To this end, it compares 
10 modes sent back from the remote station to stored 
sequences in the database. 

Non-standard Mode Mapper 

This component maps non-standard local modes, to 
specific features, by assigning mode sequences (and 

15 function calls) to an intermediate symbolic 

representation, which is then used in a feature mapping 
table. The same mapping is performed for non-standard 
remote station modes , however the mode sequences are 
preprogrammed, stored in a database descriptor, and 

20 selected according to the identity of the remote station. 

Non-standard Capabilities Mapper 

This component manages the capabilities associated 
with the non-standard modes handled by the non-standard 
mode mapper. It provides a mechanism to determine if non- 
25 standard modes are available on the remote station, as 
well as mechanism to inform the remote station that the 
local station is capable of handling its non-standard 
modes . 

CLIENT VCO ACCESS METHODS 
30 Derived from this design are several methods for 

VCO Clients to access the services of the VCO, so as to 
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make use of the VCO as an independent xnultimedia 
connectivity operating system that supports client 
sessions. 

Notes On Drawing 

5 FIG. 8 depicts the various methods used by VCO 

Clients to access service of a particular VCO. The left 
of the drawing, labeled "REMOTE SYSTEM", and the right, 
labeled "LOCAL SYSTEM", should not be confused with the 
"REMOTE STATION" or "LOCAL STATION"; access from another 

10 system may be from any computer supporting a text command 
stream to the host system, even from a dumb terminal. If 
the controlling system is a "STATION" (connected across 
the network), then it must establish a text data stream 
(in-band or out-- band) to transcelve VCO commands between 

15 the two systems. Note that the VCO depicted in the 

"REMOTE SYSTEM" is controlling the local system as its 
master, by employing some command dispatching mechanism 
to connect to the local station, but not necessarily over 
the network. 

20 BxmmwLTY of Access Methodologies 

The services of VCOs are utilized by client 
applications that construct them, and subsequently make 
calls to their member functions. Once constructed, the 
VCO lies resident in the host system as an adjunct 
25 multimedia connectivity operating system that can respond 
to requests for service, when accessed in one or more of 
the following ways: 

• Client applications running in the host 

system are able to construct one, or more, 
30 VCOs through the usual Direct Member Access 

method; that is, they call member functions 
in the VCO's Software Control Interface, to 
drive a multimedia connectivity session. 
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To provide "text command access from a remote 
system , without sending commands across a 
network connection, a VCO/TTY Access Daemon 
can construct a VCO in a host system, and 
then open a command text stream through a 
system communications port* Any remote system 
connecting to that port can send commands, 
and examine the effects of their issuance. 
A VCO terminal session is established upon 
connection to a remote system communications 
port that is being monitored by a VCO 
directly, or monitored by an Access Daemon. 
From the perspective of the remote system, 
the method of creating a teirminal session to 
control a VCO, is referred to as Remote 
Command Access. Simply put, VCO commands are 
issued directly from a remote station or dumb 
terminal, to a waiting VCO, or daemon acting 
on its behalf. 

A seamlessly integrated remote VCO control 
solution, referred to as Remote Member 
Access, is an access method that creates, in 
a VCO implementation, a Media Control Object 
that is expressly designed to establish a bi- 
directional text data stream through a 
particular system port. The VCO command/ event 
streams are directed through it, to provide a 
level of control that allows a VCO client, 
invoking VCO members on its own local system, 
to drive a remote VCO transparently. This 
method utilizes the identical components and 
mechanisms as for remote VCO control across a 
connection, except that the command/event 
stream is directed to an out-band 
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communications port, and not the principle 
network connection. 

ZMPIiEMEMTATZON 

This section describes the full implementation 
5 of a VMCS that supports concurrent live audio, live 
video, imaging, and binary data transfer services. The 
VCO portion of the system must be created to support the 
specific configuration of devices installed. Compliant 
client applications will irun over any VCO that they 

10 construct. Any number of VCOs can be created to 

encapsulate divers combinations of devices installed in 
the system. An instance of a VCO (that encapsulates a 
device set) is one of many possible presentations of that 
same device set to an application; a different VCO 

IS implementation may invoke the same devices in a different 
way, or using different drivers (for example) to present 
an entirely different perfonnance profile. Depending on 
the capabilities of the s\ib-systems installed, multiple 
VCOs can be instantiated concxorrently to provide multiple 

20 multimedia connectivity sessions at the same time. There 
is no limit to the application of the VMCS paradigm, as 
long as the specified VCO service is provided, through 
some means, to the client application or marked as absent 
in the VCO's capabilities listing. 

25 VMCS HOST SYSTEM RBQUZREMEBTS 

Implementation of a VMCS is best accomplished in a 
microcomputer host system equipped with peripheral 
devices to process audio and video signals, and a 
connection device to interface with the network. A VMCS 
30 can be constructed to run over almost any combination of 
the components discussed in the section entitled Host 
System Equipment Requirements below, depending on the 
level of implementation desired; support for concurrent 
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audio, video, image, and data services is hereupon 
described for the disclosure of full VMCS implementation, 
but any partial implementation is possible without 
affecting the basic VMCS design. The VMCS is ideal for 
5 limited usage i.e. only for audio connectivity. 

Furthermore, the bewildering array of devices for audio, 
video, data, imaging, and videoconferencing, that are now 
available, often combine the fimctionality of two or more 
devices, in which case the perceived differentiation 

10 between them exists only in the software abstraction 
layers that comprise a VCO. For example, an audio and 
video device may be combined on one board, but will 
appear as (map to) a number of discreet functional Media 
Control Object entities, whose hardware support mechanism 

15 is indeterminate, when considered at the level of the VCO 
Client application. 

Host System Equipment Req[uirementa 

Following are the requirements for the host 
computer, adapter cards, peripherals, and system software 
20 components requisite to VMCS implementation, as already 
described. Each item is intended to represent an example 
component; many permutations of features and hardware 
configurations are acceptable for actual deployment, 
though the configuration outlined below is provided in 
25 specific terms to enhance the clarity of sxibsequent 
references. 

• XBM**compatlble Personal Computer 

A Personal Computer is the preferred host 
system. It should have a Pentium processor 
30 running at 120Mhz or faster, contain at least 

sixteen (16) megabytes of random access 
memory, and a minimum of 500 megabytes of 
backing store capacity. 
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32-*Blt Multitasking Operating System 

The VMCS host operating system should provide 
protected memory address space for each 
process, support multiple threads, and have a 
preemptive scheduler. 
Oraphical User Interface 

A VMCS host operating system user interface 
should be event-driven, and provide a 
windowed graphical "object-desktop" 
environment where each visual component can 
be manipulated by 

drop/drag/cut/paste/properties operations . 
Audio and Video CODEC Devices 
Audiovisual encoding and decoding hardware 
may be integrated with other devices onto one 
or more adapter boards that plug into 
expansion slots in the computer. The CODEC 
devices for this implementation must encode 
audio and video inputs from a microphone and 
camera, respectively, to a multiplexed 
digital signal compliant with the H.221 frame 
structures. Decoding must proceed from this 
H.221 compatible signal to an analog audio 
output, and a VGA video signal for output to 
(for example) a video display terminal. 
Video Display Adapter with Overlay Controller 

A high-resolution video graphics adapter must 
be installed so as to work in conjunction 
with a video overlay device. This hardware 
configuration will support the station's 
principle visual graphics information output 
pathway by enabling the simultaneous display 
of bitmapped graphical and motion-video. This 
sub-system must permit motion-video display 



in a windowed port:ion of *the main screen, a 
region programmatically selected for -that: 
purpose. The overlay controller allows the 
display of motion-video over a region of the 
bitmapped display device by enaibling the 
real-time overlay of NTSC video frames onto 
the identified region of the main display 
bitmap . 

Audio and Visual Peripheral Transducers 

These peripherals include input devices such 
as an NTSC camera to input motion-video, a 
microphone to input audio, and a 600 DPI 
color scanner to input high-resolution still 
images. Output devices include a 17" CRT 
display (1280 x 1024 resolution that can 
display 65,535 colors) for bitmapped and 
motion -video output, a loudspeaker for audio 
output, and a color laser printer for 
hardcopy photograph and document output. 
Audiovisual devices may plug into analog 
signal ports on adapter boards designed 
specifically for the purpose of PC bus 
interface, or into standard digital computer 
ports (according to their own unic[ue 
interfacing requirements) . 
Media Access control Device Drivers. 
Device drivers must be provided for the audio 
and video adapter boards (including the 
overlay controller) enabling the 
initialization, configuration, shutdown, and 
querying of each. System device drivers must 
be available to input scanner images, output 
printer images, and control system data 
ports, among other standard system services. 
Network interface Unit (MZU) 
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A network interface unit must provide the 
physical link to the network. It needs to 
support a minimum transfer rate of 128 kbit/s 
through a plesiochronous network (see 
U. Black, ATM, Foundation for Broadband 
Networks, Englewood Cliffs, New Jersey, 
Prentice Hall PTR, pp. 36-37, 1995) such as 
that provided by the Integrated Services 
Digital Network (ISDN) . In the case of a 
host PC, the physical network connection 
extends to an ISDN phone jack, from an 
adapter card plugged into one of the 
computer's expansion slots. A fully-digital 
ISDN modem device is usable for this purpose. 
Network Protocol Stack 
The network interface must provide 
programmable software control of the physical 
network service, and in the case of the 
recommended ISDN configuration, ISDN network 
protocol software must provide accessibility 
to one or more b-channels (for encoded 
audio/video data) and to a d-channel for the 
out-band signaling required for H.320 
protocol implementation. Data packets from 
the system must be directly accessible for 
synchronous transfer to and from the 
decoder/ encoder devices (audio and video 
CODECS) « 

ISDN Basic Rate Interface (BRI) 

For the preferred ISDN network interface, the 
ability to establish a connection supporting 
128 kbit/ sec is generally accepted as the 
absolute minimum bandwidth needed to support 
a primitive motion-video image (with a 
concurrent audio signal) across the ISDN. A 
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-typical BRI installa-tion is utilized as a 
2b+ld channel conf iguration. For most: 
purposes, a triple-BRI, or coinposit:e line 
configuration (384 kbit/sec) is preferable, 
5 as it is capable of producing an image closer 

in quality to that is generally considered 
acceptable in other video applications. 

System Development Requirements 

Developing a VMCS from preexisting hardware 
10 components is a combined system and application software 
development effort. Initial development of a VCO to 
control a set of devices is a significant undertaking 
that involves careful interface to device control 
software, and implementation of many of the specific 
15 protocols residing under the H.320 rubric* While 

implementation of the prototypical VCO kernel is non- 
trivial, diligence is repaid many times over in that 
nearly all of the kernel source code is propagated, in 
rote fashion, to create a new VCO that can readily 
20 support a new set of devices. The client application 
binaries are directly re-releasable — client programs 
are fully device-independent and run over any VCO built 
to specification. Requirements to implement a VCO are 
outlined as follows: 
25 • VKCS Disclosure provides the necessary 

description of a Virtual ized Multimedia 
Connection System to derive a design for an 
actual implementation. A complete set of the 
ITU-T recommendations referenced in ITU-T 
30 Recommendation H.320, are a necessary adjunct 

to the implementation and testing of fully 
compliant protocol implementations (see 
REFERENCES) . 
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C++ Software Development system or a 

functionally equivalent object-oriented 
development system must be used to create 
both the VCO (server) and client portions of 
the VMCS. Pull implementation of the 
referenced AT&T C++ language must be 
supported. 

Developer Toolkits provided by hardware and 
software OEM's, whose components are to be 
incorporated as VCO components, is essential 
to porting the device-independent VCO kernel 
to a new multimedia connectivity sub-system. 
Software tools to create the graphical user 
interface modules (such as exception handler 
message boxes and configuration displays) 
must also be available. 

Software Development Considerations 

To restate the purpose of VMCS server components: 
it is the primary directive of every VCO to bind, 

20 dynamically at run-time, a connectivity source to a set 
of transducers; and do so in such a way that the service 
provided to client applications serves as a mechanism to 
share spectral information between interconnected 
sta ti o ns . in the use of it, no consideration is given to 

25 any intermediate data transmission methods empl^oyed. It 
is the responsibility of the VCO implementer, to ensure 
that sound and light directed to and from the remote 
station, are somehow seamlessly, automatically, and 
transparently transited over the void that may exist 

30 between data streams associated with the source of 
connectivity, and those associated with the local 
transducers. Most systems utilize an integrated 
audio/video hardware design to provide a direct analog 
signal link between these parts — consider those 
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manufacturers mentioned in the Background section — but 
this model is crippling to the station in its other 
purposes for reasons aforesaid. 

The operating system type specified for this 
5 system is characterized by the ability to spawn threads 
that run concurrently at specified priorities. They can 
be utilized to support transparent (to applications 
running in the foreground) real-time data streaming 
facilities. Data streams to/from connectivity soiirces 

10 can be attached to/ from transducers, so as to bridge any 
gap between discreet devices installed separately in the 
system; sharing data between separately installed devices 
requires read/write operations executed by the 
microprocessor (there is no direct analog signal 

15 connection between devices on different adapters) • With 
the specified operating system type, a station can take 
advantage of the multiprocessor personal computers that 
would support the transfer of data at very high speeds 
(between devices in the system) , even at rates sufficient 

20 for normal system operation, while processing audio and 
video in real-time. 

Whatever mechanism is used, hardware or software, 
the VCO implementation must create the operational 
context in the system, dynamically when invoked, to move 

25 data between system components. It must do so in a way 
that is fully protected, secure, and unaffected by other 
system activities. The creation of the sub-system^ s 
operational context must be transparent to the client 
application, as must its destruction at session's end. 

30 VCO SOFTWARE IMPI,BMBMTATIOH 

A VCO is mostly comprised of software objects 
whose member function implementations are overridden by 
more derived versions of themselves that provide 
structured access to the seirvices of installed adapter 
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devices. As the VCO architecture is a direct application 
of software object technology, to elucidate the details 
of its embodiment entails discussion of its components in 
terms of a class derivation hierarchy. Next follows 
examination of the VCO's class structure. 

VCO Class Derivation 

one VCO implementation encapsulates one specific 
sub-system configuration that exhibits a particular set 
of properties (capabilities) that defines its unique 
service profile — - unique in the set of standardized VCO 
operations it can support, but no different from any 
other VCO in the way it presents them to client 
applications. Correspondingly, each VCO is no different 
from any other in the way it is implemented. In fact/ 
there are a number of implementation principles to 
consider prior to VCO design specification, thus speaking 
generally towards application of the concept... 

• More derived classes in the VCO are more 
device-dependent, ranging from the device- 
independent VDI classes, to the device- 
dependent class PDI. 

• Less derived classes in the VCO are less 
device-dependent, wherefore all VCOs contain 
the same device-independent kernel (that is 
comprised of class VDI and all those from 
which it is derived) . 

• More derived classes are more time critical, 
ranging from the VDI that responds to 
occurrences of events in OS-scheduled time 
slices, to the PDI that can queue events 
dxiring interrupt service routines, invoked in 
real-time by device requests for interrupt. 

• More derived implementations (more device- 
independent default implementations) of VCO 
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virtual members substituted with a more 
suitable implementation overriding them with 
one more device-specific (residing in a more 
derived class); that is, a default function 
is provided by the VDI, which the programmer 
can override in his particular implementation 
of the same feature. 

In most cases, more that 90% of the VCO 
source code is reused in the next VCO 
implementation without modification, due to 
the imposition of rigorous functional 
constraints (by the VCO architecture) on its 
class structure . 

A pure virtual member interface in the 
device-independent VDI, to more derived 
device control members in the device- 
dependent PDI, impose strict isolation of 
logical from physical operations. This 
isolation of logical operations from physical 
device operations, is realized by exploiting 
object-oriented software language constructs 
integral to the language itself; structural 
integrity and layering of operations in the 
VCO is enforced at the most fvmdamental level 
of source code expression. The device control 
members used by the VDI (to lend physical 
device control to the implementation of its 
algorithms) are accessible directly in the 
same class, but the underlying device control 
mechanism is (for all intents and purposes) , 
in one more derived and not directly 
addressable. Resultantly, any changes to the 
way these more derived device control members 
are implemented, are beyond its discerning. 
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Design-level isolation of logical and 
physical device control mechanisms in the VCO 
architecture, are incorporated so as to 
intentionally expose a well-defined, readily 
exploitable "fissure" in its layering model, 
whereby the core technology is rendered 
amenable to specific extensions of concept. 
The implementations of certain system designs 
are significantly reduced in expense and 
difficulty as a direct result of the well- 
defined logical-to-physical mounting 
mechanism. Some applications of concept 
advanced by its accessible mounting mechanism 
include: 

• Rapid prototyping and redeployment for 
new sub-system configurations 

• Distributed VCO development by VDI and 
PDI development teams 

• Microcoded or embedded PDI 
implementations 

• Distributed media control systems 

• Remote station control and diagnostics 



The class derivation diagram depicted in FIG. 6 
shows the classes that directly comprise the VCO, as well 
as adjunct classes (Notif ier and MCO) that are used to 
implement its feature set. Every component shown is used 
in every VCO implementation exactly as shown. Class VDI, 
being the Virtual Device Interface used by clients to 
access the VCO's encapsulated sub-system, is the only 
class, besides the public constructor and destructor in 
class VCO, that contains public member functions. The 
symbols used to describe the various relationships 
between classes are mostly proprietary to this 
disclosure, as no widely-used convention to graphically 
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express objecti-tiechnology concepts has been adopted by a 
major standards organization. Symbolic conventions used 
here are shown in FIG. 1. 



summary of VCD Class Derivation 

5 Each VCD is a composite derivation of the six 

classes: Terminal, Exception, Event, VDI, VL, PDI, and 
VCO. In the order of least to most derived, the 
derivation sequence for the VCO itself, proceeds as 
follows: 

10 • Class Terminal enables the VCO to send text 

messages to a set of character output 
devices, or receive text messages, that are 
subsequently interpreted as commands. Since 
the VCO terminal can be programmed to use the 

15 VCO notification mechanism as a virtual 

output device, the class contains a pure 
virtual member used to direct text output to 
a Notifier Object configured for such 
purposes. This member is overridden by a 

20 supporting member function in the more 

derived class Event, and this override must 
be present for class terminal to compile. 
• Class Exception is derived from class 

Terminal, and is defined to contain member 

25 functions and data related to reporting fatal 

errors by responding in some pre-conf igured 
way. In the most primitive sense, the only 
service that class Exception must be able to 
access is some method to relay the fact that 

30 the exception occurred, and by inheriting 

members of class terminal, it can. Class 
Exception also has a virtual function used to 
shutdown the VCO when an exception occurs. An 
override in the VDI provides an 
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implementation that shuts down the VCO, as 
expected during fatal errors. 
Class Event is derived from class Exception, 
and is defined to contain the VCO event 
manager, which in turn manages the 
notification mechanism. It maintains a linked 
object list of Notifier Objects which are 
themselves each individually derived from the 
NOTIFIER data structure. Every Notifier 
Object is a protected class that is created 
by class Event, and is a friend to it. Class 
Event, but no other, can create, delete, or 
access class Notifier members directly except 
members of class Event, thus the Notifier 
Objects are essentially creatures of it. The 
event handler is the VCO's "proxy" to the 
linked list of Notifier Objects. Class VDI is 
a protected derivation of class Event. It is 
defined to contain a large set of members 
that comprise the VCO Software Control 
Interface, and a number of device* independent 
protocol support procedures. Inheriting the 
services of classes Terminal, Exception, and 
Event, it is capable of presenting the entire 
VMCS connectivity services through the member 
functions of a single binary software object; 
that is, one instantiated upon construction 
of a class derived from it. 
Class VL is derived from class VDI, and 
provides a location for an implementation- 
dependent set of routines to map physical 
device control operations and responses 
to/ from the logical representation 
manipulated by members in the VDI. Most of 
its members are private to it, and narrowly 
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focused in scope. Entry points -to translation 
and mapping services are made public to more 
derived classes that wish to utilize them. 
Class PDI is derived from VL, and contains 
within it, private definitions and 
implementations of member functions that 
override the pure virtual device control 
members used in the VDI to invoke the 
services of physical devices in the 
encapsulated multimedia connectivity sub- 
system. The implementation of the pure 
virtual overrides utilize members in the VL 
to translate and map the structure of 
arguments and input/ output data syntax to 
that expected by the VDX implementations. The 
PDI contains mechanisms to access the VCO 
Media Control Object Device Control Mechanism 
(Media Control Objects) . This mechanism 
relies upon the maintenance of a linked 
object list of instances of class MCO 
maintained much like the linked list of 
Notifier Objects in class Event. Class MCO is 
derived from an MCOPARAM data structure that 
serves as a general purpose repository for 
device control information as associated to a 
particular signal from a particular device. 
As with the administration of Notifier 
Objects, instances of class MCO are directly 
accessible only by the PDI; only the PDI may 
directly examine, modify, and invoke their 
members. The design of the VMCS is to promote 
its utilization in a variety of operating 
environments that include distributed 
systems, remote access across a network 
connection, and text command (teletype) 
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interface via dumb terminal • Members of class 
MCO are acceissible to underlying Media Access 
Control software, and MCO implementations 
make calls to the same to invoke device 
5 services . 

• Class VCO is derived from class PDI, and 

functions as the capstone for the VCO class 
structure. The only members it inherits from 
its parent classes are the public members 

10 that comprise the SCI in the VDI. Its 

constructor and destructor call those of its 
parent classes, thus it invokes those of the 
VDI to create and destroy the VCO session. 
Class VCO contains all additional 

15 implementation-specific entry points (object 

members) that are presented to client 
applications, including extensions to the 
VMCS that are not directly related to 
controlling the connectivity session. All 

20 client applications proceed with the 

expectation that the invocation of VCO 
services will always be accomplished using a 
pointer or reference to class "VCO" . 

Class Components 

25 Next follows detailed descriptions of the 

operations that must be implemented by each class 
comprising the VCO. 

Class Terminal 

Provides full implementation of the VCO terminal 
30 services by maintaining a list of output devices for the 
output terminal, and writing all text message sent to the 
terminal output port to every device on this list. Text 
messages sent to the terminal input port are assumed to 



wo 98/09213 



PCTAJS97/15018 



- 107 - 

be VCO text conuaands. They are parsed into tokens, 
decoded, and executed as SCI commands. The sub-components 
residing in this class are listed below, with an 
accounting of the specific operations for which they must 
5 provide support. 

• Terminal Stream I/O Device Controller 
Operations supported by this sub-component 
must include the following: 

• Add output device to list 

10 • Remove output device from list 

• Write text message to output device 

• Text Command Decoder 

Operations supported by this sub-component 
must include the following: 
15 • Parse text coiamand message to command 

token list 

• Verify command syntax 

• Execute command token list as SCI 
command 

20 • Text Command Encoder 

Operations supported by this sub-component 
must include the following: 

• Verify command syntax 

• Translate SCI call to text command 
25 message 

• Linked Terminal Stream I/O Device List 
The list itself is implemented as a linked 
object list, where each object contains the 
member functions and member data necessary to 

30 transmit data to the file, device, signal, or 

data port referenced by it. 
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Class Exception 

Provides full implementation of the VCO exception 
handling operations that include reporting the occurrence 
of the exception, and subsequently shutting the VCO down. 
Additional features of this component include the 
maintenance of an enable/disable flag that is tested by 
every public member function upon entry into the VCO; a 
disabled VCO must reject any call into it, and return the 
"Disabled" result code to the caller. There are a number 
of flags that can be used to configure the exact modality 
used by the exception handler to respond to exceptions, 
and each modality must be supported by the exception 
handler implementation, in accordance with the 
definitions shown in FIG. 6A. The sub-components residing 
in this class are listed below, with an accounting of the 
specific operations for which they must provide support. 
• Exception Handler 

Operations supported by this sub-component 
must include the following: 

Process VCO exceptions accordingly (see 
FIG. 19) 

Provide for capability to display debug 
information message box 
Display "user" information message box 
Send text information message to 
terminal 

Trigger Notifier on exception 
Trigger VCO disabler mechanism on 
exception 
Disabler Mechanism 

Operations supported by this sub-component 
must include the following: 

• Maintain VCO enabled/disabled flag 

• Provide for query of enabled/ disabled 
flag (see FIG. 19) 
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• Invoke system shutdown utilizing virtual 
override in VDI 

Class Event 

Provides full implementation of the VCO event 
5 management operations* A list of Notifier Objects is 
maintained, and a mechanism to trigger them is contained 
in this sub-component. The VCO event queuing and 
dispatching mechanisms are located in this component, 
though critical section handling may be located in the VL 

10 to msdce use of special operating system support for 
semaphores and thread blocking features* There are 
thirty-two (32) distinct events that have been 
standardized for VMCS use. FIG. 6C shows the symbolic 
identifiers for these events, and provides concise 

15 definitions for each. The physical source of the event is 
labeled as either hardware (HW) or software (SW) , and 
accompanied by a code that goes on to further clarify the 
specific system component from which the event is likely 
to (though not necessarily} emanate. 

20 VCO developers creating a VCO to work with a new 

device set, must identify the most reliable source for 
VCO events originating in hardware, and then map vendor- 
specific representations of the event to those virtual, 
standardized, and described in FIG. 6B« Third-party 

25 device drivers in the MAC layer may not provide access to 
events identical in meaning or context to those cataloged 
by the VCO; some interpolated or emulated derivation 
(from events closely related) may be necessary for a 
compliant indication of the standardized occurrence , and 

30 any member functions created to approximate the 

representation of one such only marginally identifiable, 
should reside in the VL layer for invocation by members 
in the PDI. 

The event manager is also responsible for managing 
35 the flow of trace information to its terminal output 
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port. The sources from which trace information emanates, 
can be programmed in an additive fashion, by specifying a 
trace output profile. There are a number of flags, 
applied to express this profile as a logical combination 
of trace output source locations within the VCO's works, 
and each modality must be supported by the event manager 
implementation, in accordance with the definitions shown 
in FIG. 6B. The sub-components residing in this class are 
listed below, with an accoxinting of the specific 
operations for which they must provide support. 

• Notifier Object List Manager 
Operations supported by this sub-component 
must include the following: 

• Create and add new Notifier Object to 
linked Notifier Object List 

• Remove Notifier Object from list and 
delete 

• Set Notifier Object triggers 

• Get Notifier Object data 

• Lock Notifier Object List against 
add/remove operations while triggering 

• * Unlock Notifier Object List to allow 

add /remove operations 

• Notifier Object List 

— The list itself is implemented as a linked 

object list, where each object contains the 
member functions and member data necessary to 
configure the Notifier Object's triggering 
profile, as well as to actually trigger it to 
deliver notification to its associated 
Notification Receiver Object. 

• Notification Triggering Mechanism 
Operations supported by this sub-component 
must include the following: 
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a Trigger Notif ier Objects in Notif ier 

Object liist (see FIG. 10) 
Event Dispatcher 

Operations supported by this sub-component 
must include the following: 

Dispatch event (see FIG. 11) 
Start dispatcher 
Stop dispatcher 
Set dispatcher rate 
10 • Configure dispatcher 

• Event Queue 

Operations supported by this sub-component 
must include the following: 

• Add event to queue (see FIG. 11) 

15 • Remote event from queue (see FIG. 11) 

• Flush queue 
Class Notif ier 

Provides full implementation of the VCO Notif ier 
Object (NO) . Each NO is a self-contained reporting 

20 mechanism called a thunk. This thunk must be created by 
any class that wishes to be informed of the occurrence of 
a VCO event. The thunk provides a globally defined entry 
point to the address space of the instantiated class 
object that is to receive notifications, and the thunk 

25 retains knowledge of the exact class name and specific 
class member designated to receive notifications (from 
the NO residing in the VCO itself) • The NO stores a 
pointer to this global entry point (the thunk) , a pointer 
to the Notification Receiver Object (NRO) , and a pointer 

30 to the NRO's Notification Receiver Member (NRM) that is 
the ultimate destination for delivery of notif ication. 
The NOTIFIER data structure from which the Notif ier 
Object is derived, contains all of this information, the 
achieved objective in its tracking to enable an immediate 

35 conveyance of a unit of system event information (a 
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Standard VCO event) directly from a driver-level 
component to the application, as soon as there exists an 
opportunity for the operating system to run the 
interested application. With regards to VMCS 
implementations and their notification mechanism, system 
designers should first reflect upon the following: 

• Notifications are designed specifically to 
operate like system interrupts, independent 
of user interface event queues. Like 
interrupts, they require service only in 
response to very specific occurrences to 
which they are programmed to respond — 
service routines do not have to test for a 
wide range of possible triggering events, but 
can act directly with simple, well-defined 
operations. 

• Notifications from the VCO are virtually 
unaffected by user- interface operations, and 
events are never lost to "queue-full" 
conditions. They are fast, configurable, 
flexible, and offer a measurably more 
reliable feedback mechanism than the typical 
GUI event delivery mechanisms, but 
expectantly can interrupt drawing operations 
in progress. Drawing operations, to display 
information delivered by a Notifier Object, 
are best executed from a specific painting 
routine, whose invocation is governed by the 
receipt of paint messages from the GUI ~ 
painting messages and graphics to the display 
with each notification can prevent the GUI 
from processing messages in its own event 
queue. 

• Consistent with the previous point, NRHs 
should be constructed as high-level interrupt 
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service routines that insert an event into 
the application's event queue (GUI event 
stream) , or spawn a new thread to exact some 
effect on the system, and return immediately « 
5 To delay processing on a notification thread 

could delay notification to other VMCS 
objects (if a single thread is used by the 
triggering mechanism to trigger all NOs) • 
Beyond delay, none of the usual problems 
10 associated with delayed interrupt processing 

occur since the VCO queue retains all events 
till processing is resumed; no information is 
ever lost. Further, VCO events are but 
shadows of real-time events that will have 
15 long since been seirviced in real-time, 

according to the methods implemented by 
driver-level vendor-specific components. 
However, correct designs for systems will 
service all outstanding event notifications 
20 and return long before the VCO dispatcher is 

ready to remove another event from its queue. 
The constructors of Notif ier Objects add them to a 
linked object list upon construction, and remove them 
from the list upon destruction; their structured 
25 integration into a linked storage format is managed 

automatically. An accounting of the specific operations 
for which this class must provide support are listed 
below: 

• Notif ier Object Operations 
30 Operations supported by this sub-component 

must include the following: 

• Find Notif ier Objects to trigger in 
linked object list (see FIG. 10) 

• Trigger individual Notif ier Object in 
35 list (see FIG. 10) 
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• Set Triggers 

• Get statistics 

• Reset Statistics 

Class VDI 

Provides full implementation of the VCO Software 
Control Interface (SCI), along with a mamber of private 
support functions. Any device-independent routine 
necessary to VCO implementation resides in this class. 
The header file VDI.H (see Appendix) contains all of the 
constants, enximerations , and data structures used by both 
server and client portions of the VMCS. Following those 
definitions, is that of the SCI. These member functions 
are the virtualized definition of the VMCS control 
mechanism from the client application's perspective, and 
are the only public members of the VCO; notably excepted 
is the VCO constructor and destructor in class VCO. Not 
shown in VDI.H are the device- independent call and 
protocol management routines that provide support for the 
VCO connectivity sessions. They are implementations of 
various Recommendation H.320 protocols. The session- 
related sub-components residing in this class are listed 
below, with an accounting of the specific operations for 
which they must provide support. 

• Network Session Operations 

Operations supported in this group of member 
functions have public entry points that are 
represented in the SCI (see Section entitled 
VDI Header File in Appendix) - They are noted 
here to reference figures that detail their 
flow control pathways. The Network Session 
operations must include the following: 

• Construct VCO (see FIG. 24) 

• Destruct VCO (see FIG. 24) 

• Open VCO (see FIG. 25) 
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• Close VCO (see FIG. 26) 

• Make call to remote station (see FIG. 
27) 

• Execute multipoint call operation (see 
FIG. 28) 

• Hang-up call or line (see FIG. 29) 
Media Control Object Device Control 
Operations 

Operations supported in this group of member 
functions are accessed by the public 
audiovisual /data signal switching control 
members in the SCI (see section entitled VDI 
Header File in Appendix) . A query flag passed 
during a call to this member function 
determines whether or not a request for 
service or capability cpiery is invoked. 
Operations supporting the service and query 
requests must include the following: 
Media control operation service request (see 
FIG. 20) 

• Media control operation query request 
(see FIG. 21) 

Device-independent Call Controller 
Operations supported in this group of member 
functions respond to line state events from 
the Device Event Processor, to manage the 
connectivity session. Call control related 
members must include the following: 

• Enter call controller and process line 
event (see FIG. 14) 

• Execute procedure to handle incoming 
line disconnected (see FIG* 15) 

• Execute procedure to handle incoming 
line dialed (see FIG. 16) 



WOM/09213 



PCT/US97/15018 



- 116 - 



10 



15 



20 



25 



30 



Execute procedure to handle incoming 
line ring (see FIG, 17) 
Execute procedure to handle incoming 
line ringback (see FIG. 16) 
Execute procedure to handle incoming 
line connected (see FIG. 16) 
Execute procedure to handle incoming 
line busy (see PIG. 16) 

Reset call data to default states (see 
FIG. 18) 

Restore default connected device modes 
(see FIG. 18) 

Set connected device modes (see FIG. 18) 
Device- independent Capability Exchanger 
Operations supported in this group of member 
functions contribute to implementing an 
algorithm that employs an H.221 mode- 
capability cross-reference table to determine 
if the connection between logical and remote 
stations can support a given H.221 device 
mode; that is, it compares the capability 
associated with the mode to the logical 
intersection of the capabilities of the local 
and remote stations. Capability exchange 
operations are internal to the VCO, and must 
include the following: 

• Accessibility to an H.221 mode- 
capability cross-reference table 

• Determine if connection supports mode 
(see FIG. 12) 

• Determine if capability is associated 
with mode (see FIG. 13) 

• Determine if local station supports 
capability (see FIG. 13) 
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• Determine If remote station supports 
capability (see FIG. 13) 

• Device- Independent Device Event Processor 
A meittber function in the VDI is a 

5 Notification Receiver Member that receives 

notifications of device events from a 
Notifier Object created by the VCO at the 
time of its construction. Any events in FIG. 
6C, whose source is identified as hardware, 

10 is considered a device event, and the Device 

Event Processor responds to them to maintain 
the current connectivity session. Device 
events are processed according to a specific 
algorithm that routes them through 

15 appropriate control flows depending on their 

particular category (see FIG. 23). 

• Pure Virtual Device Control Members 

There are no implementations of these members 
in class VDI; only the member declarations 

20 are present (see section entitled VDI Header 

File in Appendix) . These members are used 
extensively by implementations of other VDI 
members to provide the device interface for 
all operations that access vendor-specific 

25 driver components and their underlying 

physical devices. 



Class Vli 

Provides full implementation of any members 
necessary to convert, translate, map, or interpret 
30 operations and data formats between conventions used by 
logical controls in the VDI, and Physical Device 
Interfaces accessed by the PDI (MAC layer components) . 
This class may vary greatly in the nximber of member 
functions it must contain for a particular VCO 
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implementation. The header file PDI.H (see section 
entitled Physical Device Interface File in Appendix) 
contains a definition of an empty class VL to show its 
role in the derivation of the VCO. Virtualization 
operations are unlikely to be device- independent, however 
the categories of operations they commonly must implement 
Eure preserved across most VCO implementations, and are as 
follows : 

• Virtualization Operations 

• Software Component Load/Initialization 

• Software Component Unload/ Shutdown 

• Configuration Information Access 

• Data Exchange Syntax Mapping/ Emulation 

• Call Event Mapping/Emulation 

• System Information Mapping/ Emulation 

• Capability Exchange Mapping/Emulation 

• System Exception Mapping/Emulation 

• Media Access Control Mapping/Emulation 

• Protocol Mode Mapping/ Emulation 

Glass FDI 

Provides full implementation of the VCO device 
control interface, including a number of operations to 
Interface operating system services, A pure virtual 
override member must be implemented to support the 
operations defined for the pure virtual device control 
members defined in the VDI (see section entitled VDI 
Header File in Appendix). The header file PDI.H contains 
the definition of class PDI (see Appendix) and shows its 
role in the derivation of the VCO. Implementations in 
class PDI have no restrictions on the way they interface 
devices. Media Control Objects (instances of class MCO) , 
are the preferred mechanism. At the time the VCO is 
opened, when its devices are initialized, the PDI creates 
an array of Media Control Objects that describes the 
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available, and expected-to-be-available, audiovisual /data 
signal types. These Media Control Objects contain the 
member functions and data structures needed to control 
the device that is the source of, or destination for, the 
5 signal they represent to the VCO. The next section 
entitled HCO Device Control Mechanism goes on with a 
further discussion of the Media Control Object Device 
Control Mechanism. The sub-components residing in this 
class are listed below, with an accounting of the 
10 operations for which they must provide support. 

• Pure Virtual Device Control Member Override 
Operations 

Operations supported by this group of members 
are best described by the descriptions of the 

15 pure virtual member functions defined in 

class VDI (see "Class VDI") . The pure virtual 
overrides residing in class PDI are 
implementations of the pure virtual device 
control members declared in class VDI (see 

20 section entitled VDI Header File in 

Appendix) . 

• Device Capability List (H.221 Capability BAS 
Codes) 

A list of device capabilities is stored in 

25 _ the VDI (see section entitled Bit-Rate 

Allocation Signal Header File in Appendix) , 
but must be maintained by the PDI. A local 
capability list in the VL is copied into the 
VCOPARAM structure in the VDI during VCO 
30 construction. Incoming capabilities from the 

remote station are written to the remote 
capabilities field of the VCOPARAM structure, 
by callback members in class PDi, and are 
called by the connectivity protocol stack 
35 when capabilities are transmitted from the 
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remote Station. VCO device capabilities are 
represented as device-independent constants, 
so there may be a necessary mapping operation 
from the BAS code (or proprietary) 
representations used by the connectivity 
protocol stack to/ from those defined for the 
VMCS. 

Device Modes List (H.221 Device Mode BAS 
Codes) 

A list of all H.221 device modes is kept in 
the PDI as a reference. This list is used to 
determine if a mode is standeurd, non- 
standard, of a given type, or invalid. 
Device Event Linkages to Queue 
In ordeir for the PDI to be informed that 
device events have occurred, a number of 
callback functions are declared in this 
class. Such callbacks can typically be 
classified and implemented as follows: 

• Connectivity Protocol Stack Callback 
Members are called by routines in the 
software modules that implement the 
connectivity protocol. In connectivity 
protocol stacks encapsulated by the VCO, 
the callbacks come from the OSI 
transport layer (or its equivalent) . 
They call the VCO to report any changes 
in line states, the arrival of BAS codes 
from the remote station, and for a wide 
variety of status-related events, as 
defined in FIG. 6C. 

• Media Access Control Callback Members 
are called by routines in the device 
drivers that comprise the MAC layer. 
They call the VCO to report changes in 
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device st:at:es, resul'bs of device 
operat:ions, and a wide variety of 
status-related events, as defined in 
FIG. 6C. 

5 Upon receiving an event from any callback 

function, the vendor-specific event is mapped or 
translated to one of the standard VCO events, and added 
to the VCO event queue. Routines in class VL may be 
called for this purpose* 

10 Class VCO 

There are no specific components to implement in 
this class. Extensions to the VCO feature set, beyond 
those related to control of the encapsulated sub-system, 
should be added as members to this class; it is the place 
15 specifically intended for such enhancements. The header 
file VCO.H contains the definition of class VCO (see 
section entitled General VMCS Header File in Appendix) 
and shows its role in the derivation of the VCO. All 
client applications must include this file in order to 
20 access the services of the VCO itself. Class VCO is the 
class that is constructed by the client, and it presents 
to this client a number of public member functions 
described as follows: 

— • Public VCO Members Available to Client 

25 • VCO is the constructor of the VCO, and 

invokes the constructors of all less 
derived classes when invoked. 

• -VCO is the destructor of the VCO, and 
invokes the destructors of all less 

30 derived classes when invoked. 

• Inherited Public Members from the SCI 
are all presented to the client 
application as members of class VCO. 
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• Xmplementatiion-dependent: Extensions can 
declare public member functions in class 
VCO that offer their services to the 
client application seamlessly with other 
5 VCO functions • 

MOO DEVICE CONTRQI. MECHANISM 

The device control diagram depicted in FIG. 7 
shows how the VCO is able to reference the devices in its 
encapsulated sub-system as configurable representations 

10 of the data streams that they generate, process, or 

redirect. Client calls to the SCI are shown to invoke SCI 
members that, according to their specified function, rely 
on calls to pure virtual device control members for their 
implementation, thus not all SCI members are included in 

15 the diagram. The sixteen default Media Control Objects 
are arranged in the drawing to clearly demarlc the low- 
level, vendor-specific component to which they 
correspond, and manipulate when affected by PDI calls to 
their members. Vendor-specific MAC components should be 

20 considered bi-directional — they support control 

pathways and data streams to and from a media control 
sub-system — and the different types of transducers 
required for each direction are clearly evident. 
Concordantly one finds the "audio" objects reference a 

25 MAC component supporting audio input and output, and to 
that single MAC component is connected both microphone 
and speaker. PDI calls made directly to the connectivity 
protocol stack and MAC components are not shown 
explicitly in the drawing, as the exact structure of 

30 their interactions are left to the implementer ' s 
discretion. 
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Summary of Device control Mechanism 

Client calls to the SCI invoke members that often 
require the support of the encapsulated multimedia 
connectivity sub-system in their implementations. The 
implementations of SCI members, such as "Open" and 
"Call", make requests for physical device control 
services by utilizing at least one of the pure virtual 
device control member functions declared in class VDI; 
these members are private and entirely separate from the 
public SCI members offered to clients. The PDI contains 
overrides for these pure virtual device control members. 
These overrides invoke the appropriate device operations 
by making calls directly to the connectivity protocol 
stack or MAC layer components, as is appropriate to the 
desired device control operation. Implementations of the 
pure virtual device control overrides must perform any 
and all interface to vendor-specific hardware and 
software components necessary to fulfill the specified 
expectation of the pure virtual device control member in 
the SCI. 

If the particular SCI member, called by a client, 
is MediaControl, the method of interface to the physical 
device is different from that used for call and protocol 
operations; its purpose is to switch or configure the 
audio, video, image, or data signals represented as 
virtualized system objects, or Media Control Objects. In 
this case, the pure virtual override for MediaControl, 
implemented in the PDI, then manipulates the members of 
Media Control Objects that have been created to represent 
the various available signal types. Depending upon the 
exact nature of the request, audio, video, image, and 
data signals are combined, redirected, displayed, or 
routed to local devices or the remote station. The Media 
Control Objects can also be used to set various modes 
(associated with the signals) by directly controlling the 
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device associated with it. The operation of the Media 
control Object device control system is detailed as 
follows: 

• Primarily there exist sixteen default Media 
Control Objects, as shown on the right side 
of FIG. 7. 

• There is an input and output object to/ from 
the remote station for each signal type (see 
FIG. 7A) , for a total of eight objects 
representing information shared between the 
local station and the remote station. 

• There is an input and output object to/ from a 
local device for each signal type (see FIG. 
7A) , for a total of eight objects 
representing information shared between the 
local station and its local environment. 

• The objects are only created when the signal 
they represent is within the capabilities of 
the system to support. They are only enabled 
when the signal they represent is actually 
available for access. 

• Any number of Media Control Objects can be 
created in the VCO to control more devices 
and data channels, as determined by their 
detected system device availability by the 
VCO. 

• Each Media Control object, representing a 
specific signal type and direction, can be 
attached, or "plugged into" another Media 
Control Object that is compatible in both 
signal type and direction; For example, an 
audio source from a local device (microphone) 
can be attached to an audio output to a 
remote station, or a video input from a 
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remote station can be attached to an output 
to a local device (video display) 

• Each Media Control Object, regardless of 
signal type, contains a data structure that 

5 reflects the various states and modalities of 

the signal. Member functions for each Media 
Control Object, allow them to be manipulated 
as independent, uni-directional channels. 

• Certain Media Control Objects can be combined 
10 into composite media control objects that 

describe a complex signal type, such as 
multiplexed audio/ video information. The 
objects can also be combined with objects 
that subject them to a specific transform, or 
15 split/ join conf iguration, 

• Setting the parameters of a source/ input 
object invokes a sub-system (driver-level) 
attempt to change the settings of the source 
device or station, whereas setting the 

20 parameters of a destination/output object 

attempts to change the settings of the 
destination device or station. 

Audiovisual/Data Signal Switching Maohanisn 

Device control operations are made directly 
25 available to VCO Client applications through the 

implementation of the MediaControl SCI member function, 
along with some related members that assist in the 
manipulations of these objects. The SCI memJders map to 
essentially identical pure virtual device control members 
30 implemented in the PDl. The switching of signals and 
device modalities generally teJces place by selecting 
constants from various enumerated categories (see section 
entitled VDI Header File in Appendix) , and presenting 
them to the VCO with the MediaControl member* The format 
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Of the argiiments is constructed so that the specified 
operation applies to the currently assigned default Media 
Control Object for the specified Media Control Object 
type (see FIG. 7A) . For example, a coaunand to mute the 
input microphone would likely reference AudioSrc as the 
Media Control Object type. Handles are used to assign 
various non-default Media Control Objects as the default 
(one of the sixteen) for a given type. The continuous 
linear enumeration of all possible constant arguments 
used for MediaControl function calls give each setting a 
unique numerical identifier, and thus each can be 
associated with a unique string token. The argument 
formats for all of the MediaControl calls are detailed in 
the source code section (see section entitled VDI Header 
File in Appendix). 

Media control Object Physical Structure 

Each Media Control Object is a class object 
privately derived from an MCOPARAM (see section entitled 
VDI Header File in Appendix) structure. Regardless of the 
signal type (audio /video /image /data) represented by the 
Media Control Object, the MCOPARAM structure contains 
sub-records for all signal types. The programmer need 
only attend to the relevant section for the signal type 
for that object. There are a number of requirements as to 
the structure of the Media Control objects physical 
structure, with regards to the specific details of its 
implementation . 

• All member functions and member data in the 
Media Control object, are protected, and can 
only be accessed by the PDI . 

• Class PDI is a friend to all instances of 
class MCO. 
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• Class VDI cannot: access any HCOs direc:kly, 
except: through specific members that: are 
implemented by class PDI. 

- • All MCO members presented to the PDl, should 
5 be simple, device*independent operations to 

manipulate the settings and operations 
precisely outlined by the audio, video, 
image, and data records contained in the 
HCOPAKAH data structure. 

10 • Each MCO should be fully cognizant of its 

signal type and signal direction, and 
prohibit operations that are inconsistent 
with its fundamentally characteristic 
properties, i.e. cannot attach audio output 

15 to a video display. 

• The handle of a new MCO must be added to t:he 
VDI tables in DEVICEPARAM when that MCO is 
created, and removed when deleted, such that 
the client always has a clear pictiire of 

20 available system resources. 

• Events must be queued for each and every MCO 
operation executed. 

• Regardless of the complexity of underlying 
system components that must be initialized, 

25 addressed, or monitored to implement Media 

Control Object operations, it is critical 
that t:he designer reduce the invocation of 
such processes to simple operations described 
by the Media Control Object settings. 

30 MCO Interface to the Media Aooess Control Layer 

Each MCO controls the device underlying the 
signal it represents by making requests to the Media 
Access Control layer components that drive them. The PDI 
pure virtual override DevMediaControl presents settings 
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to the Media Control Objects, and the Media Control 
Objects then go on to map the setting to a physical 
device control operation. FIG. 22 shows the control flow 
for device control operations that are presented to MCI 
5 drivers that comprise the MAC layer. This diagram has 
greatly simplified the pathway from the VDI to the MCI 
driver, eliminating most of the interactions with the 
Media Control Object. In short, the PDI prepares a Media 
Control Request Record, and presents it to the 

10 appropriate Media Control Object so that the object can 
fill in its fields, and present it to a corresponding MCI 
driver (see FIG. 22) . Note that a device control 
operation initiated by the local station can result in 
the station assuming a new H.221 device mode, which is 

15 then transmitted to the remote station (if currently 
cbnnected) for station synchronization, referred to as 
the "establishment of common modes" by Recommendation 
H.320. Finally, an event is added to the VCO event queue 
describing the new Media Control Object setting that has 

20 taken place. 

STATION ATTACHMEira MECHANISM 

There are a number of considerations with regards 
to the system components that must be created to support 
the "attachment" between two interconnected VMCS 

25 stations. A pathway must be established between the two 
stations such that they can share text string commands 
streams- Once this pathway is available, the two stations 
must come to a mutual understanding how they will 
interact; that is, which station is the master, and which 

30 is the slave. 

Beyond the standard attachment mechanism 
described, a third station can control any one of a 
number of stations that are themselves interconnected in 
a conference. In this modality, a "third party" 
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controller , or "remote operator" can intervene in 
conference already in progress to assist, diagnose, or 
monitor one of the conferees. The details of designs that 
would accomplish this task are supportable by the VMCS, 
5 but beyond the scope of this disclosure. Below follows a 
description of the details for the VCO components used to 
implement the remote station attachment mechanism. 

Command Stream 

From the perspective of one end of the attached 

10 station pair, the command stream is bi-directional ~ to 
and from the remote station. A Media Control Object 
supporting text data output to the remote station, and 
another Media Control Object supporting text data input 
from the remote station, are created to encapsulate the 

15 data pathways. Since mostly text message data will be 
exchanged, the pathway need only support low bandwidth 
(less than 16 kbit/s) on an occasional (asynchronous) 
basis. Data can be transported out -band on a separate, 
channel (such as an ISDN D-Channel) or in*-band, perhaps 

20 multiplexed with video data. The data transport mechanism 
for message data can also be accomplished through a 
tertiary source using an entirely separate connection 
from that used for primary communication. All messages to 
the remote station are written to the Media Control 

25 Object encapsulating the pathway to the remote station, 
while messages arriving from the remote station generate 
events as they are received by the Media Control Object 
encapsulating the pathway from the remote station. 

Event Encoder 

30 This component converts binary event records added 

to the VCO event queue to a text event message 
representation, and then sends it to the remote station. 
A definition of the binary event record is provided (see 
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section entitled VDI Header File in Appendix) , however 
the exact text event message format is left to the system 
designer. Suffice it to say that the text message format 
used should be entirely universal to allow all VMCS 
5 implementation platforms to engage in "attachment". 

String tables in the Linguistic Controller areas of the 
VCO are used to convert the enumerated arguments to 
string tokens ^ whenever possible, while purely nvimerical 
arguments (such as parameters) are converted to ASCII 
10 hexadecimal strings. Each event message must minimally 
include the following information: 

• Event identifier 

• 3 2 -Bit parameter 1 

• 3 2 -Bit parameter 2 

15 • Source station identifier 

The event encoder is usually only accessed when 
the VCO is attached to a remote station. While the VCO is 
attached, the encoder is invoked by the VCO queuing* 
mechanism each time an event is queued. The encoding 

20 takes place using a separate thread of execution to avoid 
interference with device timing. 



Event Decoder 

This component converts text event messages 
received from the remote station and converts them to 

25 binary event records that are then added to the local 
VCO's event queue. This process is the inverse of the 
encoding process, and its success depends upon the 
consistency of the text event message format selected. 
The source station identifier tells the receiving VCO 

30 where the event caune from, and the string tables in the 
Linguistic Controller are used here to derive a niuneric 
representation by comparison of the string token keywords 
to their relative position in the tables, and derive a 
string index when the token is identified. The event 
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decoding -takes place using a separate thread of execution 
dedicated to fielding incoming command and event: 
messages. 

Command Encoder 

5 This component convert.s SCI calls to a text 

command message representation, and then sends them to 
the remote station. As with the event encoder, the exact 
text command message format is left to the system 
designer, and correspondingly, it should be entirely 

10 universal for reasons said. String tables in the 

Linguistic Controller areas of the VCO are used to create 
text command messages whose format is variable depending 
on the SCI command encoded. The command encoding takes 
place using a separate thread of execution dedicated to 

15 fielding incoming command and event messages. 

Command Decoder 

This component redirects the text command portion 
of the shared messages to the local VCO terminal input 
port, where they are interpreted, and then used to 

20 generate calls to the local VCO's SCI, just as if they 
had been input from a local user at a terminal keyboard. 
This process is the inverse of the encoding process, and 
its success depends upon the consistency of the text 
command message format selected. The event decoding takes 

25 place using a separate thread of execution dedicated to 
fielding incoming command and event messages. 

Determining Capabilities 

Each VCO has associated with it independent 
parsuneter blocks for remote control parameters and remote 
30 monitoring parameters. There are separate parameter 

blocks each containing flags that indicate their current 
operating modes, and operating capabilities with regards 
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to attachment. The control and monitoring capabilities 
are stored as nonstandard capabilities in the local 
capabilities lists, and each station will know those of 
the other at the time of connection- Once attachment has 
5 been established, it is the station that first requests a 
particular control or monitoring "context" that will able 
to assume that role. When a role is assumed, flags in the 
associated parameter blocks mark the state, and prohibit 
any further context changes till the stations are 
10 detached, disconnected, or the change is initiated by the 
"controlling" or "monitoring" station. 

Remote Monitoring 

As a subset of a full remote control context, 
monitoring of a remote station recpaires only that the 

15 "monitor" station receives a stream of the events queued 
by the "monitored" VCO. Upon connection, both stations 
are monitoring their own locally queued events; they are 
operating under £l local monitoring context • If one 
station permits (indicates it is capable of) being 

20 monitored, the other can change its monitoring context, 
by setting its monitor mode flags to include the remote 
stations events, and therefore add the events from the 
other station to its own event queue, in addition to 
continuing to monitor its own event stream concurrently. 

25 Alternately, it can monitor only those events of the 

other station, or monitor any one of a group of stations 
in a conference, as they come into focus (though a 
virtual attachment must be established with each 
individual station prior) . Monitoring can occur bi~ 

30 directionally at the same time; two stations may monitor 
each other concurrently. 
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Remote Control 

The assertion of control by one station, over 
another, proceeds similarly to the establishment of a 
monitoring context. In doing so, one station's 
5 capabilities indicate it will assume a slave operating 
context, while the other will be the master. Upon 
connection, both stations are controlling their own 
systems; they are operating under a peer control context, 
and have no ability to control the other. The master VCO 

10 initiates the transaction to request operational control 
of the other, and if consent is given by the other, it 
assumes the role of master, the other as its slave. The 
slave VCO now reacts to commands sent by the master, just 
as if the commands had been issued by its local client 

15 application. For remote control to occur, the master must 
also monitor the event stream of the remote VCO. With the 
ability to transparently send commands to a slave 
station, and transparently receive events from the 
station in response to those operations, the VCO that 

20 assumes the master control context becomes a fully 
operational virtualized representation of the slave 
station. And client applications that rxin on the master 
VCO are (practically speaking) virtual clients of the 
slave VCO. 



25 MULTIPOINT CM.1.8 

A nimber of recommendations serve to define 
standard designs, protocols, and terms used for 
audiovisual connectivity sessions that involve more than 
just a local and remote station. ITU-T Recommendation 

30 H.231 (see ITU-I Recommendation H.231, MULTIPOINT CONTROL 
UNITS FOR AUDIOVISUAL SYSTEMS USING DIGITAL CHANNELS UP 
TO 2 Mbits/s, 1994) describes such units and their 
various configurations. Attendant Recommendation H.242 
(see ITU-I Recommendation H.243, PROCEDURE FOR 
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ESTABLISHING COMMUNICATION BETWEEN THREE OR MORE 
AUDIOVISUAL TERMINALS USING DIGITAL CHANNELS UP TO 2 
Mblts/s, 1994) describes the specific operations 
performed in a multipoint call environment, such as 
5 adding, dropping, and viewing specific conferees from the 
conference. These recommendations serve as the impetus 
for the logically defined multipoint control operations 
incorporated into the VMCS server (VCO) architecture. At 
time of writing, there exist fewer than a half-dozen 
10 widely available devices supporting a significant subset 
of the procedures outlined by the recommendations. 

VCO Multipoint Control Operations 

Support for multipoint operations by the VCO 
requires the use of a multipoint control unit (MCU) . 

15 These devices have a number of NIUs, referred to as 

ports, that allow many audiovisual connectivity stations 
to attach to them conctirrently — the MCU serving 
primarily to bridge the signals from one station to that 
of many others, so as to enable a group to view an 

20 individual. A specialized algorithm determines which 

conferee, at any given time, is to be seen by the others. 
In most cases, the strength of the audio signal (voice 
presence) determines the individual that addresses the 
conference. A chairman is specified to direct the 

25 conference, and he possesses special privileges to 

administer its outplay; his responsibilities as chairman 
include the appropriate allocation of resources, the 
creation of conferences, and the configuration equipment 
as needed. 

30 The multipoint control operations supported by the 

VCO MultiCall SCI Member are shown below (see FIG. 30) . 
Calls to this MultiCall member map to the PDI 
DevMultiConnect member, one that provides an actual 
physical implementation for them. To support the 
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operations, ttixs PDI member will typically be constructed 
to issue vendor-specific commands to a MCU resident in 
the station, or cabled to it with some communications 
link. All of the major operations needed to directly 
5 control the mechanics of a conference, as its chairman, 
are included. Further discussions of these operations are 
provided in the source code (see section entitled VDX 
Header File in Appendix) . The CALLPARAM structure in the 
VCO has a number of flags and variables used to track and 
10 configure multipoint control operations. A series of 
flag values referred to as MULTICALLSTATES provide 
detailed indications as to very specific states in both 
the local VCO, and the conference in which it is 
participating . 

15 VCO IMPLEMENTATION PROCEDURE 

The procedure to implement a VCO differs 
depending on whether the project is to create em initial 
server component, or to create a new component (from an 
existing one) that will work on a new multimedia 

20 connectivity sub-system. While primary (initial) VCO 
development requires considerable effort, secondary 
(subsequent) VCOs are comparatively minor projects in 
both time and resource requirements. The development of 
VCO clients can proceed concurrently with, and 

25 independently of, that of the server (s) ; the production 
of VCO Clients requires markedly less design and 
development expertise than is required to produce the 
VCOs themselves. 

VCO Implementation Sequence 

30 The following procedure is applied to primary VCO 

development. Secondary VCO development efforts (based on 
the same design) reuse almost all components, without 
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modification, thus steps l, 3, 4, and 5 are not necessary 
to create then* 

1) Derive VCO Design 

Prefatory to development of a VCO, a detailed 
design for a specific implementation must be 
derived from this disclosure of the VMCS 
Technology. In addition to describing the 
internal mechanism, this design provides the 
definitions of the external interfaces to 
client applications, and to other VCOs 
created to run on different types of host 
stations; these specifications should be 
preserved for all subsequent implementations 
to maintain interoperability across the 
network . 

2) Establish Sub-system Operability 

It must first be determined if the 
connectivity sub-system and associated 
devices are operational. Any test procedures 
and test programs must be executed on a sub- 
system installed and configured exactly as 
specified by the particular VMCS server (VCO) 
design discussed in step 1. 

3) Develop Virtual Device Interface 

Source code development for the VDI includes 
creating all of the classes from which it is 
derived. The device-independent portion of 
the VCO is implemented as a distinct unit 
that can be built without any dependencies on 
any device-dependent, or vendor-specific 
components , 

4) Develop PDI Shell with Emulation Support 
Source code development of the PDI proceeds 
iJ^itially as an attempt to create a minimal 
implementation that will support emulation 
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for its pure virtual device control 
overrides. Calls for device support return 
"Not Ixnpleinented", or if the VDI has invoked 
emulation mode, they return an emulated 
5 response, as if a device was physically 

present. 

5) Debug VCO as Emulation Object 

Running in emulation mode, the VCO is 
debugged to verify the functionality of its 
10 device* independent portions. A small sample 

client application must be created to invoke 
SCI members for testing piirposes. 

6) Develop PDI Physical Device Controls 

Once the VCO is fully operational and 
15 debugged under emulation, physical device 

control is added to the PDX by providing a 
software linkage of the pure virtual device 
control overrides with the connectivity sub- 
system and associated devices previous 
20 emulated in software. Hedia Control Objects 

are implemented, tested, and integrated into 
the device control system. 

7) Debug VCO as Live Device Control Component 
Running in the default device control mode, 

25 the VCO is debugged to verify the 

functionality of all of its components and 
features in a "live" connectivity 
environment. A sample client application must 
used, as in step 5, to invoke SCI members for 

30 testing purposes. 

DEPLOYMEMT 

This section describes usage of the disclosed VMCS 
technology in an operational configuration* 
Consideration is given to the underlying theories of VMCS 
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operating principles, including discussions relating to 
the sequences of operations needed to manage various 
Biultimedia connectivity tasks encountered during VCO 
connectivity sessions* In essence, the following section 
5 serves as an operations manual for the VMCS, focusing 
mostly on the services provided by the VCO. 

coysTRUCTiQW 

VCO construction is a process defined by C++ as a 
10 means to create a binary software object from a class 
definition. With the VCO, the client initiates a 
construction process that is in no way different from 
that of any other class, and the VCOPARAM data structxire 
is initialized, along with other initialization tasks. 
15 Upon successful construction of the Virtual Connection 
Object, its principle data structures and capabilities 
are available for perusal. 

• Construction gives the client access to VCO 
internal data structures, use of basic 

20 device-independent services, and the results 

of a perfunctory examination of requisite 
supporting sub-components. 

• By the time VCO construction has completed, 
its dispatcher is running, and it has 

25 uploaded all configuration parameters from 

backing store. At this time, the notification 
mechanism is fully operational, and Notifier 
Objects can be created for use by the client. 

• Following VCO construction, the VCO terminal 
30 input and output poirts are active, and can be 

used by the client to send text messages to 
output devices, or to decode command input. 
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• Although the VCO may have successfully 
constructed, no drivers have been loaded, no 
devices have been accessed/ initialized, and 
there is no way for the client to know if the 

5 hardware necessary to run this VCO is 

actually installed* 

DESTRUCTION 

VCO destruction is a process defined by C++ as a 
means to destroy a previously constructed binary software 
10 object. With the VCO, the client invoices a destruction 
process that is in no way different from that of any 
other class. During the process of VCO destruction* • • 

• Xf the VCO is connected, a disconnect is 
issued — the VCO waits until the disconnect 

15 completes — and all associated VCO 

components and drivers are unloaded. 
9 The VCO dispatcher is halted, and any 
Notifier Objects are deleted, thus 
Notification Receiver Objects in the client 

20 will no longer receive information. 

• The terminal, and all other VCO services, are 
no longer available for client use, since the 
VCO does not exist following destruction. 

NOTIFICATION 

25 Once a client constructs a VCO, it can create a 

number of Notification Objects, the maximum of which is 
determined by the system designer. Notification 
indications are sent to the client immediately following 
construction, should any triggering events should occur. 
30 m The NewNotif ier command enables the creation 

of a Notifier Object, returning the handle to 
one just created as specified. When the 
Notifier Object is created, it is intimately 
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associated with one particular Notification 
Receiver Member contained within one 
particular Notifier Receiver Object, neither 
of which can be changed; a new Notifier 
Object must be created to direct notification 
to a new object-member combination. 
The DeleteNotif ier command can be used to 
delete Notifier Objects, the handle of the 
Notifier Object being used to identify the 
instance to delete. 

The EnableNotif ier command can be used to 
enable or disable the specified Notifier 
Object. Each Notifier Object can be disabled 
to stop the VCO notification process to that 
particular Notifier. When enabled and 
actively receiving notifications, a call to 
the client's Notification Receiver Object (by 
the Notifier Object) occurs to prosecute 
indication of the occurrence of an event, 
dxiring which time, it cannot be reentered by 
another such call until it returns from 
processing that event currently in play. 
The SetNotif ierTriggers command allows the 
client to change the set of events that cause 
the Notifier Object to trigger; that is, 
invoke the Notifier Object to deliver 
information to a specific member function of 
a specific class object, indicating that a 
particular VCO event has taken place. 
The TriggerNotif iers command can be used to 
trigger one particular Notifier Object, 
unconditionally, or to present an event to 
the triggering mechanism, allowing it to 
trigger all Notifier objects for the VCO that 
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contain that specific event in their 
triggering profile. 

• Notlfler Objects cannot be created or deleted 
while processing the notification of an 
event, because the internal list of Notifier 
Objects is locked. However, the triggering 
profile for the Notifier Object can always be 
modified. 

CONFI6DRATION/ SYSTEM SETUP 

There are two distinct services available to VMCS 
system users for configuration/ setup. The first is the 
ability to maintain a VCO initialization file that stores 
a text record describing all of the startup defaults for 
major categories of VCO settings, including a description 
of its network service, standard terminal output device, 
local station identity, dispatcher rate, device and 
connection time«outs, conference profile, and other 
default settings. The second is the ability to invoke 
dialog boxes containing detailed configuration/ system 
setup utilities that are provided for each of the four 
possible media types (audio/ video/ image/data) that are 
potentially handled by the VCO. 

• The initialization file is read at VCO 
construction time, and its user-readable text 
arguments are converted to an internal binary 
format stored in the VCO, accessible as a 
data structure to VCO clients. 

• The SetConf ig command allows clients to write 
a new configuration structure to the internal 
VCO configuration structure, and at the same 
time activate the new settings. 

• The RefreshConf ig command allows clients to 
upload the VCO's internal configuration from 
its default initialization file, and at the 
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sane -time activate the new settings. 
Alternately, the cosmand can be used to 
upload the internal configuration stored in 
the initialization file into a client 
configuration record, leaving that of the VCO 
configuration record unmolested. 
The StoreConfig conunand enables clients to 
store a configuration record directly in the 
default VCO initialization file, overwriting 
the existing configuration, or alternately, 
it enables clients to similarly store a 
configuration record held privately by the 
client. In either case, the data elements in 
the configuration record are converted to 
user-readable text argximents prior to being 
stored in the initialization file. 
Integral configuration utility screens enable 
end users to adjust relatively minor vendor- 
specific device driver and operating specific 
system parameters that do not map well to the 
generalized, device- independent controls 
offered by the VDI and associated media 
control device control settings. 
The VMCS concept intends these adjustments to 
be limited to those settings that are usually 
set once during initial system installation, 
and siibsequently left mostly alone; they are 
settings that tune and enhance the operation 
of the standard VCO device control 
operations, and are not intended to duplicate 
or replace them. 

The strategy behind these utility screens is 
identical to that used by advanced 
microcomputer operating systems, employing 
graphical user interfaces, whose printer 
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device driver designs require an intiegral 
"setup dialog** to enable the user to 
configure the specialized heurdvare features 
of a target printer device, prior to sending 
the job to the print queue. 
As specified by the system design, 
configuration and setup parameters adjusted 
in these utility screens are used to set the 
device default settings that are later 
manipulated through standard SCI calls to the 
device control sub-system. Moreover, vendor- 
specific configuration files are modified 
here via links to their particular private 
software component configuration scheme. 
The SetupAudioDevices command invoices the 
audio setup utility, which provides 
adjustments for microphone input sensitivity, 
frequency equalization, output gain, 
specialized physical input/ output port 
selection, noise filtering, and recording 
options. 

The SetupVideoDevices command invokes the 
video setup utility, which provides camera 
adjustments such as white balance, access to 
test modes, NTSC/PAIj mode selection, and 
focusing mode selection. Additional 
adjustments for video display include those 
that affect color, tint, hue, brightness, 
horizontal alignment and vertical alignment. 
The SetupImageDevices command invokes the 
image setup utility, which includes output 
settings for any hardcopy display/printer 
device, or video display adjustments for 
factors similar to those in the video setup. 
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Input settings for imaging devices typically 
relate to form size and ambient lighting. 

• The SetupDataDevices command invokes the data 
setup utility, which is more nebulous in its 
specific format, and whose settings may range 
from communications port settings to disk 
drive specifications for backing store. The 
VMCS meJce no presumptions as to the ultimate 
use of data streams, thus the derived VMCS 
design must specify the data setup utility. 
Typically, a VCO that directs a data stream 
to/ from a communications port will maintain 
settings for baud rate, parity, stop bits, 
and other asynchronous data transmission 
settings . 

TERHINAIi SERVICE 

The VCO terminal service provides an input and 
output port- The terminal output port functions as a 
standard output device that displays character stream 
data written to it, while the terminal input port accepts 
character stream data written to it, and interprets it as 
VCO text commands. Character stream data takes the form 
of null-terminated ASCII strings, referred to as text 
messages. The null character is used to denote the end of 
the message. Format dictates VCO text command strings 
terminate with a carriage return, and intervening nulls 
that terminate command (siib- strings) are ignored by the 
decoder . 

• Text messages sent to the terminal output 
port may be written, concurrently by the VCO, 
to more than one physical output device, 
following each client text output operation. 
Physical output devices configured to be 
written when text messages are sent to the 
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VCO terminal output port, are referred to as 
attached (to the output port) . Resultant ly, 
clients sending text messages to the default 
VCO terminal output port will find that the 
same text message has been duly written to 
all output devices attached to the terminal 
output port. 

Text messages sent to the terminal input port 
are parsed into string coxamand and argument 
tokens , and interpreted by the VCO as 
representations of SCI commands. Once a text 
command has been fully decoded, it is used to 
affect SCI member functions, thereby 
providing a scripted control mechanism to any 
VCO client; scripts can be generated by the 
local client, read from script file, 
transmitted from a remote client across a 
connection, or entered directly from a 
terminal • 

The terminal service is available immediately 
following construction. A default output 
device is identified in the configuration 
stored in the VCO initialization file, and 
attached to the terminal output port. 
A range of standard output device types can 
be added or removed from the list ot output 
devices attached to the output port. All 
output devices are written with every text 
message that is sent to the terminal output 
port. 

The ToTerminal command is used to send an 
optionally formatted text message to the VCO 
terminal output port. The command functions 
similarly to "print" statements used by 
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various programming languages that send text 
to a standard output device. 

• The FromTerminal command is used to send an 

optionally formatted text command (VCO script 
command) to the VCO terminal input port. NOTE 
THAT the terminal input port cannot be read 
for input by the client, as the term input 
refers to the provision of input data to the 
VCO from the client. The client is the source 
of the character stream. Since the VCO has no 
reason to request commands from the client 
(only the client can initiate the issuance of 
commands) the onus is on the client to send 
those commands to a mutually agreed-upon 
place where the VCO can receive them, and in 
so doing, invoke the VCO to decode them. 
Reiterated more plainly, the client "stuffs" 
script commands in a buffer, and calls the 
VCO to interpret them. 

• A Notif ier Object may be created and utilized 
as a terminal output device. When the 
Not if ier Object is attached to the terminal 
output port, it may be triggered by any VCO 
(or client) text output sent to the terminal 
output port, thereupon the Notif ier Object is 
explicitly triggered so as to make the 
client's Notification Receiver Object the 
recipient of every text message sent to the 
terminal. This mechanism allows any client to 
direct all text message output to a client's 
text processing routine. 

NETWORK SESSION 

Establishing a network session is accomplished by 
invoking a sequence of SCI members. Construction and 
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destruction of the VCO frame the connectivity session in 
that a VCO is usually selected and constructed just prior 
to connecting to a remote station, and is subsequently 
destructed immediately following the termination of the 
5 connection to it, therein freeing all system resources 
erstwhile allocated to the maintenance of that 
association. The process of associating two stations 
across the network, for the purpose of exchanging audio, 
video, image, and binary information between them, is 
10 advanced by a sequence of VCO operations next described: 

• The Open command initializes the encapsulated 
multimedia connectivity sub-system, loading 
and starting all supporting vendor-specific 
software components. Until the **open" is 
15 performed, only non-device related VCO 

services are active. All devices are started 
and tested to determine that they are fully 
operational. All available signals are 
represented in newly created Media Control 
20 Objects, and then are opened for use. The 

entire sub-*system, including all hardware and 
software components, is set to default 
startup settings, and the network connection 
is verified. If the open is successful, a 
25 connection can be established at any time, 

and all local devices are accessible to the 
client, to be controlled by the user. 
Incoming calls from a remote station may be 
handled following a successful open. 
30 • The Call command initiates a call to a remote 

station. In the preferred VMCS emboddLment, 
the network is the ISDN (telephone system) 
and the "call" operation results in a direct 
dialing of the number of the remote stations 
35 line(s) . Just as with a standard telephone. 
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the visual telephone service provided by the 
VMCS requires no further action by the 
client, and a simple result is returned ♦ A 
successful connection process results in the 
execution of an internal VCO process to 
establish a series of baseline operating 
modalities for the type of session 
established. For the visual telephone, a 
video window is displayed showing the far 
end, remote station audio is audible, and 
both local video and local audio are sent to 
the remote station. Image and binary data 
facilities are initialized as idle, and 
pathways await client operations to exchange 
information. In short, the "call" operation 
of the VCO's visual telephone system worXs in 
an identically analogous fashion to making a 
"call" with a standard analog telephone: 
dial, coxmect, then concurrently exchange 
information bi-directionally, without delay. 
The MultiCall command enables the initiation 
of a number of complex multipoint control 
operations (see FIG. 30). If the local 
station is the conference chairman, the VCO 
client can add and remove conferees from the 
conference, among other administrative 
functions, all of which require the ability 
to control a multipoint control unit (in some 
direct or indirect fashion according to the 
actual physical implementation of the VCO 
service) . Other multipoint operations include 
various query and broadcast operations that 
may or may not require an advanced level of 
MCU control. The client can query any of 
these operations to determine if they are 
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currently supported by the session in 
progress. The client can determine if the VCO 
implementation supports the operations at all 
by examining the VCO capabilities list, which 
5 includes multipoint control capabilities that 

are proprietary to VMCS technology. 
• The Hangup command enables the client to drop 
one, or more (all) lines used for the current 
call. Similar to the "call" operation, the 

10 "Hangup" operation of the VCO's visual 

telephone system works (by default) in an 
identically analogous fashion to the "Hang- 
up" of a standard analog telephone: end the 
call without delay. 

15 • The Close command shuts down all devices in 

the multimedia connectivity sub^system, and 
unloads all vendor-specific software 
components. All client access to device 
control services is no longer available, and 

20 Media Control Objects are all destructed. 

Neither incoming, nor outgoing calls may be 
handled, and only the non-device related 
services remain active. 



MEDIA DEVICE CONTROL 

25 Device control is available to the client by the 

manipulation of Media Control Objects via calls to the 
MediaControl SCI member. The VCOPARAM structure contains 
a list of the names of all available Media Control 
Objects active in the system. This list will be empty if 

30 the VCO has not been opened first, as the list of Media 
Control Objects reflects the signals available for 
manipulation by the client. A list of the handles to 
these Media Control Objects is also available, and 
information about them may be obtained using the 
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appropriate SCI member function. Principles governing the 
control of the devices in the encapsulated sub-system^ 
and their associated operations, are shown below: 

• There are four signal types (audio, video, 

5 image, data) and four signal directions (to 

remote, from remote, to device, from device) 
from which sixteen Media Control Object type 
permutations are derived. These are the 
sixteen default Media Control Object types 
10 that may be addressed by type in operations 

(see FIG. 7A) . 

• Following successful completion of a VCO open 
command, any available signals in the VCO are 
represented as Media Control Objects, 

15 automatically opened for use, and enabled. 

They are not switched on initially, but must 
explicitly be turned on by a client command 
or by connection to a remote station. 

• The MediaControl command enables clients to 
20 change the settings for any active (existing 

and enabled) Media Control Objects assigned 
to be one of the sixteen default types. 
Additionally, switching of signals (in the 
form of plugging together source and 

25 destination Media Control Objects) , creating 

composite signals from multiple input 
signals, and a host of related functions can 
also be accomplished with this command (see 
section entitled VDI Header File in 

30 Appendix) . 

• The SetOefaultMco command can be used to 
assign a non-default Media Control Object as 
a default Media Control Object, if it is the 
same type as the one it is replacing. 
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The GetHcoHandle command can be used "to 
retrieve the handle to an Media Control 
Object from its name label or object type. 
GetMcoLabel is a command that allows the name 
label for the Media Control Object to be 
determined from its handle. 
The GetMcoParam command can be used to 
retrieve the internal parameters and settings 
for a specified Media Control Object, and 
thus it can be used to determine the 
operational states and settings of the signal 
represented by the Media Control Object, as 
well as the device (if any) that is the 
source or destination of that signal. 

15 BIXOKY DATA OBJECT EXCHl^GE 

Data Objects may be exchanged with single 
operations, between stations that are both running a 
VMCS; each of which fully understands the data formats 
and "transport layer" protocols of the other end. For 

20 now, such issues eure left to resolution by the system 
developer who must determine the exact protocol used to 
transfer the VCC s data objects as described herein. 
Though lacking in international standardization, 
manipulation of binary data objects is operationally well 

25 defined and described to client applications by the VMCS 
(The Software Control Interface and the logical 
manipulation of which is clearly implemented in the 
"session layer" residing in the VDI) . Fortuitously, the 
ITU is currently working on Recommendation T.120 (Data 

30 Conferencing) to enable standards-based exchange of 
binary data objects. A case could be made for the 
utilization of this VMCS model for all connectivity 
software systems on the sole basis of its ability to 
insulate applications from the ongoing T.120 



10 
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specification, and the complexity of its implementations. 
As of this writing, T.120 remains incompletely specified, 
only partially implemented by any real products, and even 
less well understood by system developers. It is expected 
s that T.120 will eventually provide the "language" 

necessary for the VCO to conduct its "binary data object 
exchanges" below the " session layer** , in an entirely 
standards-based fashion. 

If the remote station is not running a VHCS, 

10 simple data buffers and cursor positions may be sent 

according to existing procedures for information sharing 
in H.320, but support to transfer entire binary and/ or 
text files may not be available. If it is determined that 
the remote station connectivity sub-system is a 

15 compatible VCO (using the IsVCO command) , then any data 
object can be transferred. Otherwise, if the data object 
to be transferred is a file, the remote station will be 
unable to respond to the VMCS proprietary file transfer 
protocol used on the data channel. Support for the 

20 exchange of cursor positions, facsimiles, still pictures 
(images) and raw data buffers is supported by most H.320 
compliant stations, and thus possible between a VMCS and 
any remote station to which it may be connected. The 
mechanics of exchanging data objects between stations are 

25 discussed below: 

• The Trans ferBuffer command enables a client 
to send a buffer of binary data through the 
data channel (or multiplexed data channel 
using an allocated portion of its total 

30 bandwidth) , to the remote host. This command 

can also be used to determine if the data 
channel to the remote station is available. 

• The Transf erObject command enables a client 
to send or retrieve a specified data object 
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through the data channel, or multiplexed data 
channel . 

• The transfer operations specify a Media 
Control Object whose data signal is used to 

5 transport the data* If the remote station is 

running a VMCS, the direction of Media 
Control Objects signal determines whether the 
transfer operation sends local data to remote 
station (data to remote) or is a request to 
10 retrieve data from the remote station (data 

from remote), 

• The Media Control Object used for the 
transfer contains data structures and 
variables that describe the actual status of 

15 the transfer* 

SYSTEM IKFOXUfATZON 

Access to system information is highly restricted, 
from the view of the client, and is only available 
through SCI members. These members handle a wide variety 
20 of VCO states and parameters, and provide that 
information to the client in divers formats: 

• A number of VCO states and conditions are 
reported by SCI members returning boolean 
results* These boolean test members allow 

25 clients to determine if the VCO is ready to 

make a call, if a call is currently being 
setup, if a call is connected, if a 
multipoint call is in progress, if the remote 
station is a VCO (running a VMCS) , or if the 

30 current VCO exists in more than one instance* 

• References to copies of data structures, 
stored internally in the VCO, are returned 
for those specific categories of information 
relating to devices, configuration, call. 
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protocol, control, and monitoring parameters. 
One member returns a reference to a copy of 
the entire VCO system information data 
structure. 

5 • The internal data structure of a Media 

Control Object can be accessed in a way 
similar to other data structure, with the 
client specifying the default Media Control 
Object type, or a handle to one. Also, the 
10 handle for a Media Control Object can be 

obtained from a Media Control Object label or 
the Media Control Object* s type. 

• Text names for most enumerations, constants, 
and system objects can be retrieved from the 

15 VCO using any one of a number of members 

designed to return labels to them. 

PROTOCOL H&NAGEHENT 

The H.320 protocol defines the basic operational 
structure of the VCO's multimedia connectivity services, 

20 and from the standpoint of the client, is mostly 

transparent to its functionality. An exception lies in 
the VCO support for the manipulation of device modes and 
capabilities; it is useful for the client to affect the 
system's capability list, as well as the set device modes 

25 directly. Moreover, such access allows more knowledgeable 
clients to perform advanced, or less well supported 
operations at a low-level. 

• A data structure in the VCO, referred to as 
PROTOCOLPARAM, provides the client with 

30 infoznnation about the H.221 multimedia 

connectivity protocol. A full accounting as 
to the progressions of which, is provisioned 
by this useful data structure, specifically 
with regards to current and pending device 
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modes for audio, video, datia, and 
miscellaneous operatiions. 

• Tlie SetConf Prof ile command enables the client 
to specify a conference profile that 

5 describes a preferred set of audio, video, 

and data modalities (relative to the 
available bandwidth of the connection) that 
define the overall quality of the 
connectivity session. 

10 • The SetModes command enables the client to 

specify one, or more, H.221 device modes by 
presenting them to the connectivity sub* 
system. This command is used in conjunction 
with the VerifyBandwidth command to determine 

15 if there is sufficient bandwidth available in 

the connection to support a specified set of 
audio and data modes, while retaining the 
ciirrent video mode. 

• The SendCaps command enables the client to 
20 transmit its entire H.221 capability list to 

the remote station. 

• The SetOeviceTimeout enables the client to 
specify the number of milliseconds the 
Network Interface Unit should wait for a 

25 response from a network request before timing 

out, whereas the SetConnectionTimeout enables 
the client to specify the number of 
milliseconds the system should wait for a 
connection to a remote station to complete 

30 prior to timing out. 

VCO CONTROL OPERATIONS 

A large group of operations enables the client 
application to adjust, control, and invoke special 
features of the VCO . Some of these operations enable the 
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manipulation of internal VCO settings that are typically 
left to their default settings for most sessions. A 
number of commands are used by a client to attach to a 
remote VCO for the purposes of remote control and/ or 
5 remote monitoring of it* 

• The EnableVco command is used by the client 
to alter the state of the VCO's "enable" 
flag, a task usually reserved for recovery 
from an exception that previously disabled 

10 it* The SetVcoExceptMode is used to set the 

exact modality used by the VCO to handle 
exceptions. 

• The SetVcoTraceMode command is used to 
instruct the VCO as to exactly which 

15 operations and components should be 

configxured to direct trace information to the 
VCO terminal output port. 

• The EnableHultiCallOps command is a simple 
switch that is used to select the client' s 

20 accessibility to the multipoint control 

operations. To disable these operations 
causes them to return "disabled" to the 
caller. 

• The EnableDispatcher command is used by 

25 clients to pause the dispatching of events 

from the VCO event queue. This operation is 
used when the client wishes to "idle" the 
VCO, while allowing underlying devices to 
function as best as they may. The related 

30 command SetDi spat cher Rate enables the client 

to change that rate at which events are 
dispatched from the VCO event queue, a task 
usually performed when a faster or slower 
event stream is required by the client 

35 application; faster dispatching rates allow 
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the client to operate at speeds closer to 
those of the encapsulated multimedia 
connectivity sub-system* 

The UpdateCapsList command is used by the 
client to add or remove a device capability 
to the VCO device capability list^ a version 
of which is transmitted to the remote station 
during the connection process. A related 
command, UpdateModeCapsXRef , allows the 
client to add or remove a mode-capability 
cross-reference record that is used when the. 
VCO attempts to establish common operating 
modes with its remote station peer. 
The BmuControl command enables the client to 
access an internal VCO emulation facility. 
Features include enabling/disabling the VCO 
device emulation mode, and invoking 
predefined emulation sequences. 
The AttachToRemote command is used by the 
client to provoke the VCO to attach to its 
remote station peer, if that peer is a VCO 
(rtinning a VMCS) . The DetachFromRemote 
command eliminates any attachment between 
interconnected VCO peer stations. When the 
VCO is attached, the SetVcoControlMode 
command is used to select the master, slave, 
or peer modality of operation for the local 
station, with respect to the remote station. 
The SetVCOHonitorHode command enables the 
client to select the event stream for the VCO 
to process. Events from the local station, an 
attached station, a group of stations, or 
some combination of station are directed into 
its event queue for subsequent dispatching. 
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• The SetStationLabel cosunand is used to assign 
a text label to the local station so that it 
may be referenced (locally or by a remote 
station) by that name. 

5 SAMPLE CLIENT APPLICATION 

Source code in this disclosure (see section 
entitled Sample VCO Client Application in Appendix) 
illustrates the use of VCO services by a multithreaded^ 
event-driven VCO Client application. This simple program 

10 does not utilize a graphical user interface, but directs 
its output to the standard output console. The program 
examines a VCO's capabilities to determine if it supports 
required audio, video, and data modes, and opens a 
connectivity session if it does. Source code is also 

15 provided for the many header files used by both the VCO 
Clients and the VCO itself. 

The Invention is meant to cover all of the above- 
mentioned alternative approaches as well as others not 
specifically mentioned. The above-mentioned embodiments 
20 and others are within the following claims. 
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3490 



3495 



3500 



35X 



3535 



SOURCE CODE 
VDI HEADER FILE 



VIRTUAL DEVICE INTERFACE HEADER FILE 
for 

ViRTUAUZZD MULTJMEDU CONNECTiON SYSTEMS 
ABSTRACT 



Tto» loufce module caimini dermwons far die pnneiple loftwiic efmmenaaas. uimmi. d*a simemret lad ine»i>cr 

i«np«e«en«non. m »m. form of caa^T^m 
^m«aaon. n« de«»e uuemce eonipoaems »e oHenal (non^»blic> n d« VCO. and «e of da pu«« yinBTSST AUrtTr 
fimeaoM. ,aue«ire». int cotuans riumn below .re o«d by every VCO to enble unxoired iccLs IXbL»L^ 

«n«for every VCO m,p.«„en»non. d«u eaebimj e,e»o„ of devKe-urtependem connecovny .pphaoom^. e^Sil di^lr 
330S ISOVRCEFILE. VDl.H) 

, _. PROCRAMMINC NOTES 

u *?1.^!!!rr"""" '^■^"^ ^' ^""^ »«Bg d« • // • nooao. lo denote eommemi idduim 

3510 * 

ca,2^^ ""^T^ '^"^ "* • condidon. Of rtqisesied openiion dux can not be idemiftcd: (hac u tte usage of cbis wonJ 

33IS L^.'^HTf'^ "^T ' """^^ " »»«"'»» "tai u idendriable. but is imppnqmite given du: eunem 

MI3 s"«fP«condiiiOM:Uaiud«B»uageofd«uwordcoiiiioiBiuiippfopri»teixi«o/conaja. ™ cunem 

4^ wn .ic(p«m refen to u oceunenee of • severity Hut warmi. sbwdomnem of die coiaeeiivjiy sufa-fysiem (a fatal enorl- 
such » oewnenee eoonnn swuficam desiafailiiation of die VCO has occurred uid ftirdter usage risks a system ensb. 

'^"»." r '"here u a -.IsSiocldng- to d« caU. ahd 0 

L ^ ™«*^"' *"■"»« «h* »Pc«~on u> eotnplea. lypieaUy remnung -peiriiBg- if d>e fequcsr 

3323 



6. AU cluneier potmen tehar-) poiia to mU-ttmunaiedASCn amg, of a (engrA ttu thai 256 chanatr,. including die ouU. 



ASCUMENT SYNTAX 

for 

VIRHJAL CONNECTION OBJECT EVENTS 



^^^^!L^^^r^ ' ""^ CoBCOiotl Object event is initiated »he> . nooficaooa object in d« l»« VCO 

diuu. a «,fr«„ rt,^ du. eoi»«> a»nb.r functtom ™pl«me..,ed speetfically „ respond spproprutelv a> dm tyji of systetn 

3540 EVOfTTOENTTFlER PARAMETER I PARAMETCRJ 



Don't care Oaa'lcare 

NtwEmnState Tme if ctmdation cnaMtd Oaa'lcare 

■K^^ ^ir^^ •«: EMUUA-nONOP > Ooo'ieare 

MtwRrtCoMt Previous refeieoec count New reference eoum 

NewOeftcaSOM < DEVICESTATE > Do,m u^ea 

J^wMwFoei.. < MCO_TYPE > Pir » media crrt ob, labei 

newucaicapa Prevuws nunter capaUllnei New number capabdines 
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3350 



3555 



3560 



3565 



3570 



3575 



NewRcmouCips 

NcwRcvModc 

NswXmtModc 

NewReJModt 

NvwAttdioSMtittt 

NewVtdcoStttlBg 

NcwlnsftScuiBt 

NewDsuSttUnc 

NcwCallSuu 

NcwUntlSuia 

N«w|Jn«aSUt< 

NewCoofPnfllt 

NtwDtseSutui 



NvwMnUtCaUOp 

NcwOataSUcrStau 

NtwRevBttflcr 

NtwXmtBufftr 

NMrRcvOblMl 

NcwXntObJcct 

NtwVcoSUte 

NcwCtinorFM 

NcwTcmiDimt 

NewTcmOutput 

NtwRcmkCodc 



< 
< 
< 
< 
< 
< 



I > 
i > 
I > 
> 



Previous namber capabiUdet 

< BASCODE > 

< BASCODE > 

< BASCODE > 
MCO SCTTTNG 
MCO SETTINC 
MCO SETTING 
MCO SETTING 
CALLSTATE > 
UNESTATE > 
UNESTATE > 

< CONFFROnLE > 

< RESULTCODE > 

< MULTICALLSTATE > 

< MULTICAUjOP > 

< XFERSTATE > 
Number of bytes received 
Number of bycet auumiaed 

< MCO XFEROBJ > 

< MCO XFEROBI > 

< VCOSTATE > 
HiRb-wond U X. low-wofd is Y 
Number of bytes tnnimmed 
Number of byies i 

< RESULTCODE > 



New number cspabUicies 

Don't emre 

Don't care 

Don'i care 

Paruneter for seimig 

Pinmeier for seumg 

Patameier for semng 

Pifsmeier for semog 

Don't care 

Don't care 

Don't can 

Don't care 

Don'c care 

Don't care 

Don't can 

Pit id media cat obj label 
Ptr Bi mcdta cut obi Ubel 
Per to media art obj label 
Pet to XfeiObjeci 
Ptr to XferObjeei 
Don't care 

True if relaave co previous 
Pit to message smng 
Pirm message string 
Pit to mvokmg cmd string 



35S0 



3585 



// BASE DATA TYPES USED IN ALL VCO SOURCE MODULES 
typedef uhstgned char 



lypedef unsigned tm 



QfpBdef 
cjrpedef 



DWORD 
DWORD 
DWORD 
DWORD 



BYTE: 
WORD; 
DWORD: 
BASCODE: 
EV ENT: 
HNOTIFIER; 
HMCO; 



// Mit unssgnsd value < standard octet) 
// 16-btt unsigned value 
// 32«biiisiistgi)ed value 

// 32-bit Ottngned H.231 bii-nte sUocation signal 
// saudaid VCO even tdendfier type 
// 32-bti hiadte used u> refetetce stgnai objects 
// 32-bit hiidle used to reference media cot objects 

// IMPLEME^fTATION-DEPENDENT CLASSES DEFINED ELSEWHERE 

etau XfeiObi«: // Base daa for sll tremfer object descnpmrs 



«ype 



3590 



' ffTANDARD VIRTUAL CONNECTION OBJECT EVENT IDENTIFIERS 



3595 



3600 



3605 



3610 



3615 



EVENT NullEvem 
EVENT NtwEowSlau 
EVENT NewEmaOp 
EVENT NcwRslCooDt 
EVENT NtwDeviccSUtt 
EVENT NewMeoFactts 
EVENT NewLMlCapf 
EVENT NtwRoMteCaps 
EVENT NewRcvMode 
HVENT NftwXmMode 
EVENT NewRilModt 
EVENT NcwAudioScltiiig 
EVENT NcwVldcaScttiiig 
EVENT NtwlmogaStttlBg 
EVENT New DataScitioff 
EVENT NcwCaliStett 
EVENT NewUaelSftate 
EVENT NewUaaZStatc 
EVENT NcwCoalPMUc 
EVENT NewOiseSlauis 
EVENT NiwMutUCaOSUte 
EVENT NtwMumCaDOp 



' OaOOQOOQOt: 
I OxOOOQQOQZ; 



> OxOQOOOOIO; 

■ OsOOOOOCnO; 

• OxOOOOOO«0; 
'Os OOOOOO aO; 

* OxQOOOOlOO: 

■ OaOOOOQZOO: 
>0« OOOOQ 400; 

* OsOOOOOSOO; 

> OaOOOOIOOO; 

I o^oooonooo* 

> 0x00004000: 

• OxOOOOSOOO: 

• OxOOOtOQOO: 
' OxOOOZOOOO: 

* 0x00040000: 
I 0x00080000: 

> OxOOIOQQOO: 



// NO^P to evem preeessor 
// New VCO < 
//New 
y/ New VCO I 
// New media comol devtcs late 
// New 'cunem* medU ccrl Obiect has been set 
// New local capability list avsxtable 
// New remote capafailtiy lUi available 
// New device mode set by remote siaoon 
// New device mode set by local sanon 
// Attempt to set device mode rejected 
// New setting for audio object 
// New scomg for monon-video object 
// New setimg for imagutg objeet 
// New setting for bitsneam object 
// New call state 
// New line I state 
// New line 2 sate 
// New cenfefenee profile for call 
// New dtsconnect status from network 
// New muiiipontt call sate 
// New nndtipoim call openuon complete 
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3620 



36Z5 



3630 



EVErn- 

EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 
EVENT 



NcwDauXferSute 

NewRerfiitfrtr 

NewXmiBafrcr 

NcwRcrObJcct 

NewXffitObJcci 

NewVcoSUte 

NewCnnorFos 

NewTftnnlopttt 

NcwTcruOutput 

N«wRcsttitCod« 

RCMTTCd 



■ 0x00200000: // 

■ 0x00400000: // 
' 0x00800000: // 

• OxOIOOOOOO: // 
' 0x02000000: // 
' 0x04000000: U 

• 0x0 8000000 :// 
' 0x10000000: // 
: 0x20000000: // 
> 0x40000000: // 
' 0x80000000: // 



New daa aamfer saie 

New daa buffer receive complete 

New dsn buffer cnnsroixsion compteie 

New dui obreci Rcenre comptcie 

hiew dia ob;cct cnnsmusion comptefc 

New gtobal VCO sae 

New cursor postoon from remote sgmhui 

New text message m VCO (ro VCO lermiuJ input port) 

New cexi mesxage from VCO (to VCO temuial output pom 

New result code from ituerprcted VCO command 

Reserved tmptemenatton-dependem evem 



NUMERICAL CONSTANTS 



363S 



3640 



int M«xI)ttTtcc9 » 2: 

tm MaxObJForDcv « 3: 

int MuMcoTypc « 16: 

int MaxXRcf - 3; 

im MaiModts • lOO: 

im MnCsps * tOO: 

im MasUbcs - 2: 



ENUMERATED CONSTANTS 



// Max loimber encapsulated devices 
// Max mtmber media ctrl obieca per device 
// Max number of media ctrt object types 
// Max nmitoer mode-<ap refs per record 
// Max number toal H.22I device modes 
// Max outnber total H.221 device capabilides 
// Max tines manageable by ctU conoolter 



3645 



36S0 



3665 



3670 



// VIRTUAL CONNECT OBJECT GLOBAL OPERATIONAL STATES 
lypedef eaun ( 

v!S!^' " inirialiifd and opennonai for calling 

v"*?!!!?' VCO is nMopeimoonaJ; no calls possible 

experienced failure, but is suntsi operaoonal 
VGODUnUad. // vcO has been disabled and is no longer opcraminal 



) VCOSTATE: 

// EXCEPTION HANDLING MODALmr FLAGS 



36S5 


ExcepcModeDebuf 


-0x01. 




ExeeptModeUser 


- 0x02. 




ExeepcModeTetm 


- 0x04. 




ExceptModeNooTier 


« 0x08. 




ExcepcModeAbort 


« 0x10 


3660 


} EXCEFTMOSE: 





// TRACE OUTPUT MODALITY FLAGS 
lypndcf rmpu ( 



TncoModeDevice 
TcaccModeNoiifier 
TnccModeMCO 
TisoeModeCaU 
TncsModftUiK 
TncdModcPtoiD 
} TSACEMOOB: 



-OxOt. 
-0x02. 

- <ht04. 

- 0x08. 
-0x10. 
-0x20 



// Tnie etiables output debug info in msg box for exeeption 
// True enables output 'user' info in msg box for exceptioD 
// True eittbtes sendmg exception info to terminal devices 
// True ctablcs rcponmg of excepnon by mggenng notifier 
// True enables abon of ops. and disables VCO on excepnon 



// Tine eiubtea all low.|evcl device bub 
// True enables noiirtcanon cvem axes 
// Tmte enabtea media col obfcct ncs 
// True eiables high-kvel caU corurot 
// True enables tow-4evel caU axxl liiK 
// True enable all protocol trace ouipui 




// VCO CONTROL MODALITY FLAGS 
typedef emsra { 

CoriModcPeer -0x01. 
3675 CorlModeMuier - 0x02, 

CoriModeSlave • 0x04. 

) CONTROLMODE: 



n True sets local direct local acceu possible 

// True sets local as master to conoot remoce VCO 

// True sets local as slave to remote VCO 
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36BO 



36as 



3690 



3693 



3700 



3705 



3710 



3713 



3720 



3723 



// VCO MONfTOR MODALITY FLAGS 
rypedcfcfBunC 

MooModeLacal * QxOI. 

MofiModcRemote • 0x02. 

MonModeAmy > 0x04 

} MONITORMODE: 



// True sets monitonng to inchide local uuion 

// Tnie lea monitonng to include remote saoon 

// Tiue sets monitonng imy of soooos tn conference 



//TERMINAL OUTPUT DEVICES FOR ATTACHMENT TO VCO TERMINAL OIHTUT PORT 
typedef enum ( 
TennODevNoDfier • OnOI. 



TcRsODevFite 
TennODevSireun 
TermODevMCO 
} 7BRMQDCV: 



"0x02. 
«0xO4. 
- 0x08 



/'VCO EKiUl-ATTON OPERATIONS 
(ypedef cnum ( 

DixaUeCAllEautMode. 

EntUeCaOEmuMode. 

SecCiUOstSodon. 

SeiCaUX>sd4eu. 



UnelOisc. 

Uoe2Dtsc. 

RanfinmLiMlDiic, 

RaadQinLuie20isc. 

LiaslRii«. 

UaalRingteek. 
LinelRifigback. 
UnolConiieet. 
Luie2Conaect. 
OneLinBliicominc, 
TwoUnelncomiog, 
OaeUiieOuigotag, 
TweUaeOmgoinf. 
OncLineOucgoingfiuty. 
TwoUncOu^oiiigBiisy, 
^)i>eLanBOiiigoiBgRe|, 
TwoLineOutgomgRej. 
TwoLineFtdiCaimienDiseRqsu 
OneUneAuteOniy. 
OiiBUneAudtoVidea. 
TwoLineAudioVldeo, 
TwoLincAudioVideoOaa. 
CiUEoBilaiianOpEad 
) EMULATIONOP: 



// Nodfier is cenninal ouipui device 
// File, or Ate system std device, as tenninal ouqxii device 
// System daa scream as Knmnal output device 
// media ctrl Object as lenmnal output device 



// Disable VCO call emulason mode 
// Eiablc VCO caU emulanon mode 
// Set remoce host as a user-souion 
// Set Rinois host as an MCU 

// Eimilate fatal VCO ewepooti <reeovenble in this case) 
// Emulate disc online 1 
// EmnlatB disc on line 2 

// Emulate disc on line I at nu^ora time (w/in I mini 

// Emulate disc on line 2 ai random ome (w/in I mm) 

// Emulace nngmg on liw t 

// Eimilans nngmg on liiK 2 

// Emulate nagtauclt on ttw I 

// Emnlaie nngback on line 2 

// EmulaiB connect on Uiw I 

// Emulate connect on line 2 

// Emulate 1 line incoming call 

// Emulate 2 line tncommg call 

// EmulatB I line ouigoiag call 

// Fnmliiff 2 line oucgoif^ call 

// Eionlate I line outgoing call to busy reonce 

// Fmnlifr 2 line outgoug all o busy reaoiB 

// Enilais I line outgoing caU diat is rejeeod by remote 

// Emulate 2 line ouigotng caU diat is RjeciBd by remote 

// Eimdate 2 tine caU to comect. dte disc n(st by remote 

// Emulate l line audi»«nly caU 

// EmulatB I line auditKvideo call 

// Emulate 2 line audio-video call 

// Emulate 2 Line media ctri call 
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// MXn.TlPOINT CONTROL OPERATIONS (mj-T H.231. ITU-T H.243) 



3730 



3735 



3740 



3745 



SeeConlFociu. 


// Set conference foctu id tpecifted mton 


QucryCon/Focui. 


// Oetemune it&uoo curmnly tn ccnference focus 


SetCottfQttir. 


// Set conference cta&imun 


QucryConfChftir. 


// Detemune current conference chainnen 


AddSamm. 


// Add saoon to confemKe 


lUiBOveSaooa. 


// Remove icaoon from conierence 


BravtcascAudto. 


// Emble/Diubte broadcast of local audto lo conferees 


BmidusiVideo. 


// Enable/Z>isable broadcast of local video u> conferees 




// Enable/Disable broadcast of local data to conferees 


GetNnmStMDom. 


// Get number of conferees 


GetSaBonLiu. 


// Get list of conferees 


OctSttcnnCipi, 


// Get list of conferee capabilices 


GctSttoonAudio. 


// Get audio from panicular conferee 


GetSttiumVideo. 


// Get video from panieuiar conferee 


GciStuionDtsB 


// Get daa from pamcular conferee 


GeiSBBonidenmy, 


// Get numbers and (if possible) label for remote scatioi 


MultsC«110pEad 


) ftfULTICAIXOP: 





3750 



T755 



3760 



3765 



3770 



3T75 



3780 



3785 



3790 



if VCO UKTVERSAL RESULT CODES 
lypedef enuni ( 

&lGBeS5, 



TmedOut 
Rcduodutt. 



NoiSuppoRBd. 
PfDcessTeimBaied. 



MustBeClosed. 



QueiisEmiMy , 
QucuclnalL 
Memory AUocEnor. 
RAaotuceAtlocEfTor. 

ThBerfaihin. 
Uodefiaedftesuli. 



lawaUdDataType. 
lovtlidOeviceRGaiin. 



ImntidOpefisonNow* 

toyilirtCipihiluy, 

IfivilidMHle, 

InvaUdUoB. 

lnvalidNoiificr. 

IsvslidOfatiect, 

lnvtUdSeoing, 

InvalidPanm. 

CndSjmauiErTor. 

ArgSyttBuError. 

NotEooagbBandnnddi. 

CallMiistBeCofinecsd. 

NoCaUForLuieAdd. 

I. mftfiPnwn. 

LmeConnectFailed. 

LiBeNotConnccttd • 

UDelsBmy, 



ff Openoon failed for some unspectlted reason 
// Openoon comptettd mccessftOly 
// Openoon u pending: scandby for eompiefion 
// Openoon tuned otit 

// Openoon sets mode or vahie that is already in fbiee 

// Openiion possible, but denied for some reason 

// Openoon b i»i yet implemetned. but is fonta comin g 

// Openoon u not supponed by diis implemenaoon 

// Openoon depends on process that has been lerniimted 

// System capable of requested openoon/eonfigunoon 

// System not capable of tecptesiBd opeimm/configiinaon 

// Spe cifi ed objecx imist be opened prior to openiuin 

// Specified object imist be closed prior to opeisiion 

// Specified Amotion disabled to prevcm ftmher system eomipiiiw 

// SpeeifiBd object resootce u in use by anotber process 

// (>teue is empty (no removable ofajeco available) 

// Queue is fitU <no more obfeeis can be insened) 

If Memory could not be allocated to suppon openoon 

// D c p cn d em resource could not be allocaied due to error 

// Some unexpected serious inseraal error was detected 

// Could HOC configure omer m modulate praceacuig 

// Openoon result indctemunaie: don't ta»w what happened 

// Specsfted saoim has invalid spec, or is for some reason unknown 

// Data specified for arg is of wreng qrpe: such as a mill pv 

// Rcann code from device driver is unrrpcrtrd or unkaown 

// Sotaented opeiation/eTent is unknown 

// Enunenied operaaon/evem is known, but unexpected u this tins 

// Specified capability is t w i f ipr c int or unknown 

// Spectfted mode tt unexpected or unknown 

// Speeifted line is unexpected or unknown 

// Specified nottfier is unknown 

// Specified o^ecs is tmtnawn 

// Specified seomg is unknown for this object 

// Specified panmecer is unknown for thu setcng 

// Syntax error in 'command' portion of message 

// Synax error in 'arg* pomon of message 

// Not eixwgh bandwidth for requested openoon 

// Operation only possible while caonecied co remote staoon 

// AiKmpt to add unknown conferee 



// Lflie cmmectioo failed 

// Line has nm yet fully connected 

// Line is busy 

// LiiK disconnect is tcqocsted 
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379$ 



3800 



38QS 



3810 



3815 



3S20 



3823 



// DISCONMECnON RESULT CODES FROM NETWORK LAYER 



DiicSsuusUndeftDBd. 
DucSamiNonml. 
DiscStuisProioeolEmr. 
DiscSaus.O.PrtfixNocAllowcd. 
DiscStanu^l.PnfivNoiAtlowcd. 
DiscSiaeus* l^PrcfUReqnired. 
DiscSaauinvalidNumber. 
OiicSiuuinvalidAmCode . 
DiscSiuttiNunibefChaiited. 
DUcStttusRenHneBttsy. 
DiieSanuNoAfifwcr. 
DUcSaoisCillRejected. 
DiseSaouRcmoteUnavaiUbte. 
Oiir SnnnNewrottEnor. 
DiicSaouCiU?itnD|NBd. 
Db 

DiscSaBuQiuUiyUnavaiiaMe. 
DiirSnnifCompmcrRacUMwUiblc, 
DiieSatuiKWCoarisunaoiiEiTor. 
TMnySttnuThinKofirtlr 
DtacSaoaChanTypeNodxnplem. 
DucStuufaeilityNotSufasentaed. 
Diir,SriiuiFacilityNodmptenu 
DttcSaiiuNoAooiToOest 
DiseSaaaalnvalidNumtaerFonnat. 
DueSaauNumberRe^tttred. 
RcailiCadcEiid 
} RESULTCOBE: . 



Oiic saou tntieates undefined condtoon 

Disc uanti indicates noiwai 

Disc suus indicsttt protocol error 

Disc staott indicates xero prefta is not allowed 

Disc staws indicates one prefix is not allowed 

Disc suius indicates one preflx is required 

Disc stauu uidicaus invalid number 

Disc siatua indicates invalid area code 

Disc same indsates number has changed 

Disc siaaa indicates lentote line is busy 

Disc saius indicates no lemote answer 

Disc statue indicates remoie rejected call 

Disc siaou inriirarrt rcnuxe is unavailable 

Disc sams indicates network error 

Disc staou indicates caU preempted by other call 

Disc taau mtiieates outgomg calls are barred 

Disc saou inritcatft mcoming calls are barred 

Disc tanu inrticatft requested quality unavailable 

Disc taou indicates computer resource unavailable 

Disc scams udtcaies hardware canfigunoon error 

Disc satus udicates channel not idle 

Disc sanu tndieaies channel cype not unpiemeiued 

Disc saus indicates facility not subscribed 

Disc stems indicaas iacilicy not unptememed 

Disc scams indicates no toot to descinaison 

Disc saius indicates invalid rannber format 

Disc satus indicates number required 



ENUMERATED CALL COKTHOL CONSTANTS 



3830 



383S 



3840 



// INDIVIDUAL UNE STAIES 
cypedef eaim( 



LitaBuiy. 
Litiefting, 
LincRinyback. 



}UNE?rATE: 

// CSNERAL CALL STATES 



//UCKIS 

//Line is dialed 
// Line is busy 
// Line is rinfing u local 
fi Line is ringing at remoa 
// Line is 



3845 



CallConnecimg, 
CaOCoBnected. 
CallSaaEal 
) CALLSTATE; 



// CaU is fuUy du 
U CaU is in the precess oi conneeBng 
// CaU is fiiUy i 



3830 



38S5 



n CALL DESTINATION 

{ 



NoDesQiaoon. 



RemoteStaoen. 
LocalMCU. 
RemoieMCU. 
ICALLDCT: 



// No specific call desiinatien dearmiiKd 

// CaU to local station <uiconung call) 

// CaU to reit»a saiion (outgoing caU> 

// CaU to local mutcipoim control unit (bicamuig call) 

// CaU to remote station (ouigoutg caU) 
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// MULTXPOINT CALL STATE FLAGS 





lyped^f enuxn ( 




3^60 


IsMultiConnected 


-OxOOOl. 




UConfFocus 


• OxOOOZ. 




IsConfChftir 


- 0x0004. 




URcvingConfAitdto 


a 0x0008. 




URcvtngConfVidea 


. - OxOOIO. 


3863 


liRcvingConfDaa 


- 0x0020. 




IsBidcasangAudw 


- 0x0040. 




IsBcdeunngV^o 


- 0x0080. 




UBrbcuongDta 


« 0x0100 



} MULTTCALLSTATE: 

3870 

ff CONFERENCE CONNECnvrTY PROFILE 
cypedcf eoum ( 

UseAittUoOnly, 

UscVideoOnly. 
3873 UiftOaaOnly, 

BenDaoOnly, 

BenAudioOnly. 

BesiVideoOaky. 
} CONFPROFILE; 

3880 

// DATA TRANSFER STATES 
rypedef enum ( 

XferRcady. 

XfemngOaa. 
3885 XferReiryini. 

XfcrPmmed, 

XfcrFuUire. 

XfetWotR r tpnnrting. 

XferlfuenalEmir. 
3890 } XFERSTATC; 

// MEDU DEVICE CONTROL STATES 
typaief eiuin { 
DftviccOpeo, 
3895 Devteedaicd. 

t>evtceF»iled. 
DeviccBusy. 
DevlecMClFaaurc. 
DeviecNotRespondtng . 
3900 DeviccimenttUEfTDr, 
) DEV1CE5TATE: 



-165- 



// Locxl scuhHi is connected to tnon fbin one remote <or MCUS 

ft Local saooa has conterence iocus 

// Loeal siaoon u conference cluimun 

// Receiving conference audio 

// Rccttivmg conference video 

// Reccivmg conference dau 

// Braideaiiins local audio 

// Btoadcasong local video 

// Bmirirainng local daa 



// Audio sharing only 

// Video sharing only 

// Data xharuig only 

it Phoney to Oata sharing quality 

// Priortiy to audio sharing quality 

// Piioriiy to video sharing quality 



// Ready to nnsfer <idle) 

// Transferring data 

// Tramfer teaytng 

// Transfer paused 

// Tramfer fiuled 

// Transfer process not responding 

// Transfer process unemal error 



// Device is iniiiilixrd and operaoonai 
U Device is noi opendonal 
// Device failed 

// Device ts already in use and unavailable 

// Device dnver fsihire (Media Control Interface failure) 

// Device u not responding 

// Device tnietnal error detected 
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3903 



START CONTINUOUS LINEAR ENUMERATION OF MEDIA CONTROL OBJECT CONTROL TOKENS 



// MEOU CONTROL OBJECT TYPES 
(ypedefumm { 

Q. 



3910 



3913 



3920 



3923 



3930 



3935 



3940 



3943 



39S0 



3933 



AiMtioSit. 
AudiaOst. 
Vidootfu 
VideoOut. 

VidMSlC. 



baagcOut. 
KoiateSfc. 
ImigeOsi. 
Daaln. 
0«BOut. 
OmSrc. 
DsaDsi. 
ObjTypeEivl 
) MCO.TYPE: 

// MEDIA COffTROL OBJECT SIGNAL TYTES 
cypedef eoun { 

SignOln » ObjTypeEnd. 

SignalOut. 

SigntlSrc. 



SigntlTypeEnt 
} MCO.SIGTVPE; 

// MEDIA CONTROL OBJECT COMPOSTTE TYPE 



AtMlio iignal from remoie saoon 
Audio iignai lo remote suoon 
Audio signal from local device 
Audio signal co local device 
MoBon-vidfio from remote smion 
Modon-video co remote siziiiHi 
MoQon-video from local device 
Modon-video to local device 
Image from remt»B station 
Image to nmote sianon 
Image from local device 
Image to local device 
Bti seream from remote stanoa 
Btc smam to remote scanon 
Bit stream from local device 
Bit scream xa local device 



// signal from remote saaon 
// signal to remote sbqod 
O signal from local media eomrot device 
// signal CO local media cooool device 



{ 

Diacreet • SigoalTypeEnl. 
Mctged, 



Dcflultiptexed. 
Timtfonned. 
CostpostteTypeEad 
) MCO.COMFTYPE: 

// DATA TRANSFER OBJECTS 



( 

XHerNoObyeci - CompastieTypeEnd. 
XfeiCunorPos. 
XfefScnng, 
XrexTcJuFile. 
Xfer&lnFile. 
XfeiObfEi^ 
} MCO XFEROBJ; 



// Mnbiple inputs to san 
// Multiple inputs mixed imo complex single 
// Multiple imxns encoded into smgle ouqiui 
// siBgle mixs decoded into multiple outputs 
// single in^ subjected co specific oansform 



// No specified data tnnsfer object 

// Cunor Posicion 

// Nuttnenninaie ASCII text stnng 

// Text fUe 

// Binary file 
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3960 



396S 



3970 



3975 



39B0 



3985 



3990 



3995 



4000 



4005 



4010 



4015 



// MEDIA CONTHOL OBJECT St MINOS 
lypedcf Mum { 

// BASE OBJECT SETTTNGS 

NoSemng - XfefObjEnd. 

Open. 

Close. 

EmMe. 

Dtnblc. 

On. 

Off, 

ABKhTo. 
DottchFfotn. 
AddToComposiK. 
RemoveFromComposite . 
SeflCompositsType . 



CecCi|is, 

// MOTION-VIDEO SETHNGS 

SetColorkey. 

Assign Window. 

UnassignWindow, 

Resile Window, 

SetSoetcbOn. 

SeiSiretetaOfr. 

SediBiSeType. 



Unftveze, 
SciP ropomo tuiOn. 
SetPropofiionalOfr. 
SctVideoFrameSize, 

// IMAGE SETTINGS 
/* AtfigaWiiidow. 
UBusignWtndow. 
eWindow. 



SrtStrrirhOfy. 

SetlmaseType. •/ 

SednuigeMeinc, 

SetPixelWidib, 

SeiPiulHeisbu 

SeiPbceiOepib. 

SetPfaysicaiWidth. 

SetPbyiicalHeiflu. 

SciHofzPUelOngin. 

SeiVenPixelOfigin, 

SecHofzPliystcaiOnyin* 

SctVcftntirstcilOrigin* 

SetHonPixslOeanty, 

SeiVcnPixelDcttsity. 

VilnagrCombiaeType , 

// AUDIO SHTTINCS 

SctAndioQuaiity. 

LtpSynehOn. 

IkpSyvctOff, 

EdtoCancelOn. 

FcMTanrrtOff, 

SesDTMFDuntton. 

LoealOTMFPutse. 

BoBOieOTMFPuUe. 



// No speafiG setnng 

// Open object (inicialixe md render operaoanii) 
// Close object 

// Enable object (make svailabte for use) 

// Disable object tmake unavailable for use) 

// TUm on object signal 

// Turn off ofctrect signal 

// ABach object signal to another object signal 

// Detach object signal fiom another object signal 

// Add object signal lo composite signal 

// Remove object signal to composite signal 

// Set modality of composiu signal 

// Get staus of objca signal 

// Get capabilities for objea 



// Set motion-vtdeo color-^ey vahie for display 
// Assign ffloiioii-vtdeo display to specified window 
// Unassign mooon-video display from window 
// Resize (refresh and rulign)numon-video window 
// Sec moson-video stretch mod* cm 
// Sec mocion-irideo stretch mode off 
// Set monon^ideo image type 
// Fiecxe inoiion*video signal 
// Unfreeze mocioa-videa signal 

Sei moQOfHvideo prspomoiBl mode on 
// Set monoii-video pnspoiiituial mode off 
// Set video fnme size 

// Assign imaging display to window (already defined above) 

// Uiassign imaging display fram window (already defined above) 

// Resize (refresh/realign) imaging window (already defined above) 

// Sec imaging saetch mode on (already defined above) 

// Sec imaging stretch mode off (atready defiited sbtrve) 

// Set imaging image cype (already defined above) 

// Set imaging image metrie type 

// Set imaging image pixel width 

// Set imaging image piael height 

// Set tmagiog nage pixel depdi 

// Set imaging iaaage physical width 

// Set imaginf tmage physicai hetghc 

// Set honzoBial image ptsel oiigia 

tt Set veracai innge pizel oiigin 

// Sec hrmimifal image physical origin 

// Set verdcal image pixel origin 

// Set horixocnai inuge pixel deasicy 

// Sec veracai image pixel dcnsny 

// Set image combine type 



// Sec audio signal qualicy 

// Turn on lifKsynchreiiizadon of audio signal to video signal 

// TVira off l^synchnminrinn of audio signal to video signal 

/f TXim echo cancrilsiion on 

// Tbni echo cancrHition off 

// Sec dial tone mortal ition frequeiKy pulse duration 

ff Pulse OTMF at local scaoon 

// Pulse DTMF at remote staiicm 



4020 // DATA SETTINCS 
SetDuRate, 
SetSyncXferMode. 



// Set dan transfer rate 

// Set synchronous data transfer mode 
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SetAsyacXferMode. 
SeOUsmciBdModc. 
4023 SetUiucstnctcdModc. 
MeoSeaingEiid 
) MCO.SETTINC; 

// BASIC IMAGE TYPES 
4030 lypcdef emtm ( 

Nolnoge * McoSemngEnd. 
Colarlmife, 
Gnyacatelmasc 
BiamUnage. 
4035 ImageTypeEnd 
) IMACETYrE: 



// Set tsynehrofioui daa cnnsfer mode 
// Set mincted dati tnnsfer nxide 
// Set unreuncted dau nitsfer mode 



// No tnuige available 
// Color image lype 
// Gnyicale image lypc 
// Two-tone image type 



4040 



4045 



4050 



4055 



4060 



4065 



4070 



4075 



// IMAGE METRJC5 
typedel emira ( 

InchMeihc] « tmageTypeEnd. 

CemMeincs, 

MiUiMevies. 

MicmMeoies. 

ImagcMechcEsid 
} IMAGEMETRIC; 

ff IMAGE-ON-IMAGE COMBINE TYPES 
lypedd enum ( 

Owtey m iraageMetncEnd. 

Replace, 

Cotorifey. 



// Set 'inch* as pnmary measure 
// Set 'ceimmeter' as iirimary 
// Set *mtUtmetcr' as pnmary . 
// Set 'micremeier' as pnmary 



//Overiay 

// 



( 

NoVideo ■ imageComtiineTypeEnd, 

QuuttidF. 

FuUCZF. 

CIF240. 

4CIF. 

VideoSiseEnd 
) VIDEOSIZE: 

// AUDIO SIGNAL QUALTTY 
typedef emun ( 

NoAudio m VideoSizeEnl. 

VoieeLow. 

VoiceHigh. 



BitiHieGR. 
BinmeXCR. 
BicwiMAND. 
iDngsCombineTypeEod 
) IMACECOMBTYFE: 

// MOTION-VIDEO FRAME SIZES (TTU-T H.261) 



withsoince 
widisomce 

// Overlay deidnabon defined by colorfcey with iouice 
// Oreitay desnoanon wiui temporary outiiM of source 
// Combine testinatum and sowce widi biiwiiB OR 
// C o mbin r desimanon and source widi bitwise XOR 
// Combine d e mn a n on and souicc widi bitwise AND 



HighFideliiy. 
AudioQiuJiiyEnd 
) AimtOQUALTTY; 



// No video signal 

// Quaner-tizc Common Imermediate Format video image 
// niU.size Common Imenixediate Format video image 
// Common Incennediaie Format video image widi 240 tcantn 
ff Four-oines Common Intermediate Fonnat video image 



// No audio signal 

// Low quality voice signal (usually 8Uiz sample rate) 
// High quality voice signal (usually B-ltkhz sample nte) 
// Music iiuaiicy signal (usually 22khz sample rmtek 
// High fidelity quality signal (usually 44kliz sample imie) 
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4080 



4083 



4090 



4093 



4100 



// DATA TTLW^SFER RATES 
typedefenum( 

DualUteNone • AudioQualicyEnd. 

DaaiUte300. 

DiaiUtel200. 

DsiifUte4800. 

DaaRate9600. 

OaaiUieUKb. 

D«ilUte2aKb. 

DiaRitt64Kb. 

DuaRatel281Cb. 

DaaRacel92Kb. 

DaaiUte236Kb. 

DaafUte320Kb. 

DwlUte384Kb. 

DaaRAie312Kb. 

DftaRaie 1152Kb. 

DauRace 1336Kb. 

DaaRaieEnd 
) DATARATE; 

// LAST VAUD MCO TOKEN VALUE (VSBD FOR BOUNDS CHECKING OF ARGUMENTS) 
typedef emun { 

MtdsaOMroCTokeoSMi DaaRudBnd 

}: 



if No dia innsfer 
// 300 baud tnnsf er nte 
// 1200 bud innsfer nte 
// 4800 btud mnsfer nte 
// 9600 baud cnnsfcr nie 
// 14.4 kilobaud iniufcr nte 
// 28,8 kilobaud innsfer nte 
// 64 kilobaud tnosfer nte 
// 128 kilobaud oansfcr mc 
if 192 kilobaud nnsfcr nte 
// 2S6 kilobaud tncufer nte 
// 320 kUtrtmid tnnsf er nte 
// 384 kilobaud innsfer nte 
// 512 kilobaud mrafer nte 
// 1152 kilobaud innsfer nte 
// 1336 kilobaud transfer nte 



4103 END CONTINUOUS UNEAR ENUMERATION OF MEDU CONTROL OBJECT CONTHOL TOKENS 



// STRUCTURE FOR VCO EVENT DESCRIPTOR 
street agEVENTKEC ( 
4110 DWORD Id: 

DWORD Panml: 
DWORD Panm2: 
STATION* pSacion: 
BOOL UFramDcvice: 
4115 taBEVENTREC* pNeai: 
agEVENTREC • pPn v ; 



); 



// 32-bit VCO event idenifier 

// 32-bii event parameter 1 

// 32-btf event panimter 2 

// Pir ID source soiioa 

// Tnie U event generated by encapsulated 

// Pir o near event in queue or list 

// Pir to prerioua event in queus or list 



4120 



4125 



4130 



nrpedef ogEVENTKEC EVEfOREC: 

// STRUCTURE FOR STATION DESCRIPTOR 
s gy gt a gSTAT lON ( 



DWORD 
cbar> 
dur* 
BOOL 

ogSTATlON- 
cagSTATION* 



Id: 



); 



pNamber(3): 
UVco: 
pNoxc 
pPnr: 



// Syaem idemtfler/tndex used to refer co this saaon 

/ Prm sanoa label - 

// Amy of pen to nimben of renuie stadon 

// Tnte If Rtnott sation is decmuaed to be a VCO 

// Pv to next miioB in list 

// Pir to previous scaoen in list 



lypedef agSTATlON STATION: 



// DEFINmON OF EVENT HANDLING MEMBER FUNCTTON 

cypedef DWORD EVENTFROCC 

4133 EVENT ^Id. //32-bit event idendfler 

DWORD 'Panail. // 32-bii event paiameier I 

DWORD 'PaninZ. // 32*bii event panmeter 2 

STATION* ^pScuun. // Ptrio desenptor for saoon originating evcra 

HNOTIFIER" hNocifier // Hanlle to ooiiricaiton object oiggered by event 

4140 ); 
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4145 



4130 



4153 



4160 



4165 



4170 



4175 



4i«0 



4185 



// STKUCTURE FOR VCO NOnRER DESCRIPTOR 
cypedcf nnact { 
DWORD TriffKi: 
pObfeci: 
pMember; 
UEiobled: 
OidyOevtceEveno; 
TiTriuciui; 
RemmDau: 



EVEWTPROC 
BOOL 
BOOL 
long 

DWORD 
) NOnFIER: 



// MMk ipeeirving events that tngger this noafttr 
ff Prr 10 Nonfier Receiver Object (NRO) 
Ptr 10 notuier tandJer tnemOer of NRO 
// Tnie if nonfier ii enabled to cng ger 
W Tnie if nonfier triggers oniy for device evems 
// Number ot umes nocirier mggered since last reset 
// Data rewmed by noiiftcanon haivUer member of NRO 



// STRUCTURE FOR RED-CREEN-BLUE COLOR SPECIHCATION 
typcdef struct ( 

2^5 " ^ component 

a YTT ST"* componcm 

//Blue color component 

) RGBVALUE: 

STRUCTURE FOR DEVICE DESCRIPTOR 
lypedef stnict < 
DEVICESTATE Sw: 



HMCO 
} DEVICE: 



pVcnion; 
nObfcctt: 
phMCO; 



// Scale of physical devke 
// Pit to label for physical device 
// Pit to venion string for physical device 
// Number of media cirl obiects associated wiih physical device 
« Prr to amy of handles for meda ctri objs asstxiated with device 



/^STRUCTURE FOR MEDIA CONTROL OBJECT AUDIO PARAMETERS 
(ypedef smtet ( 

AUDIOQUAUFY Q«.»|,y; // MCO aud« <,i«iiiy 

hStcO SiSSSI?^' // Ttue if audio lip-synchrumzed witi, video 

SS?^ S^SSSSLon: ;;H-»«»«o»'»^.ynchn.mzedvideoo*^« 

^ »»™CancelOn: // True if echo cancellanon is enaWod 

) MCO.AUDIOPARAM: "^^"^^ " ^ ^one Modulation Frecp«ncy dunnon 

CONTROL OaiECr MOnON.VIDEO PARAMETERS 



BOOL 
BOOL 
BOOL 
BOOL 
BOOL 

IMAGETYPE 
VtDEDSIZE 



KsAssignedTaWtn: 
tsWtnUpdaied; 
IsFioxen: 



} MCO.VtDEOPAXAM: 



ImageType; 

VideoSizB: 

pDispliyWin; 



// Tnie if obj assigned to wtntow 

// True if wuidow tligned widi source video 

// True if moooi>-video is fioaen 

// True if roonon-vidco preporoonai mode is 

// Tnie if monon-video stretch mode is on 

// Motion-Video image type 

// Motion-video fnme «* Tf 

// Pit to assigned dispUy wiivlow 
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4190 // STRUCTURE FOR MEDZA COKTROL OBJECT IMAGING PARAMETERS 



4193 



4200 



420S 



4210 



4215 



4220 



422S 



4230 



4235 



4240 



4245 



42S0 



BOOL 


IsAttignetfToWtn: 


BOOL 


IsWinUpdated: 


BOOL 


IsFfOXsn: 


BOOL 


IiPraponxonaii 


BOOL 


USoetcbed; 


IMAGETYPE 


BasisType: 


DwlAGECOMBTYPE 


CombType: 


IMAGEMETRIC 


UugeMetne: 


im 


PUelWiddi: 


101 


PixdHcqhu 


im 




im 


HorzPUelOngin: 


im 


VeriPijcdQhftn: 


uu 


HofzPuetDeiiiiiy ; 


im 


VenPixelDeasity: 


im 


PhystcalWktib: 


im 


PhysicilHctgbi: 


im 


HofxiHiysicalOhgin: 


im 


VcitPhysicalOnipn: 


Window" 


pOtspUyWm: 



) MCO.IMAGEPARAM: 



Tnie if obja assigned to wtntow 

Tfuc if window aligned with source video image 

Tfue if imaging is frozen 

True if imagmg proporaorat mode is on 

True if imaging stretch mode is on 

Basic image type 

Image combine type 

Image pnmary measure 

Image pixel width 

Image pixel height 

Image pixel depds 

Image honzomal pixel origin 

Image venical pixel origin 

Image honzooai pixel density 

b»a«e venieal pixel density 

Image piiystcal width 

Image physical height 

Image honzonal physical origia 

Image vettcal physical origin 

Pit to assigned display window 



// STRUCTURE FOR MEDIA COhTTROL OBJECT DATA PARAMETERS 
cypedef stmct { 

800L liSynehioneus: Tnie tf data Butsfer u synchmmius 

BOOL IsResncted: // Tnie if baiHlwidih is resmciBd 

^OOL IsCompositB; // Tiuo if pait of eomposiie 

DATARATE TfuuferRate: // Data nntfer sue 

} MCO DATAFARAM* " Composite oaiufcr nee (if pan of eomposue) 

// STRUCTURE FOR MEDIA CONTROL OE/ECT DESCRIPTOR 
cypedef sDiict ogMCO ( 
char* 

MCO TYPE 
MCO SIGTYPE 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 

MCO AUDIOPARAM 
MCO^VIDEOPARAM 
MCO IMAGEPARAM 
MCO OATAPARAM 
DEVICE* 
} MCOPARAM; 

// STRUCTURE FOR MEDL^ CONTROL OBJECT BINDING RECORD 

tows a«MCO_BINDING ( 
™^ " IfCmnpmtf r: « Tnie if binding is » produce composite sigml 

I™ oStc: Nmnber of source media Ctrl obfeca 

jw^ nOst: //Number of destnaacton media Ctrl objects 

HMCO phMcoSfc: P«r to list of handles for source media ctri objects 

phMeoDst; // Pbt to list of handles for destmanon meda Ctrl obieci 

ogMCO.BINDING* pNext: // P(r to Mat biivlsng recotd 

^ tt»MCO_BINDING* pPwv: // Pir to ptev binling tccoid 



pLabel: 


ft 


ObjType: 


11 




// 


IsValal: 


tl 


IsOpen; 


// 


IsEnabted: 


II 


IiOic 


II 


tsABCbed: 


II 




II 


IsBuay: 


II 


IsEttoOitod; 


11 


Audio: 


11 


Video: 


11 


Image; 


II 


Dam: 


II 


pOovice; 


It 



ictit obieci is on 
I media est o^eci is aiached m aaodter media col objea 
f media art obieci n pan of composite 
f media art ofe^ca is busy (unavailable) 

I or cnnip i riMd ; lUse if not 
i (if ludto iype> 
r Mock (if video type) 
r block (if image type) 
r block (If data lypej 



typedef agMCO_BINDING MCO.BENDINC: 
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4235 



42fiO 



4263 



4270 



4275 



4280 



42as 



4290 



4295 



4300 



4305 



4310 



4315 



4320 



/i^UCTURE FOR MEDU CONTROL OBJECT COMMAND RECORD 



( 

MCO.TYPE 
MCO SETTING 
DWORD 
) MCO^CMD: 



Type: 

Seamc 

Pinin: 



// T»ffei medu Ctrl object lypc 
// Sesbng for media etrt obfect 
// Pamneter for scnng 



ii^Sl^ MODE^TAPABIUTY CROSS-REFERENCE RECORD (ITU-T H.: 



221) 



} 



DWORD 

iiu 

DWORD 



Value: 
nRcf^; 

ReOMaxXRefl; 



// Mode or capabilicy value to be crou-fcferenced 
// Number of cmss-rcfereiees for mode or cap 
// Lin of referenced modes or caps 



'UI^?^^ CAPABILITIES USTINO (ITU-T H.22I) 

■ypeoef struct ( 

flASCOnt ^ Number of H.221 device captbiitixes 

} mVC^, Cap(MazCap,|; // Lanng of H.221 device capab^, 



// STR UCTVRE FOR CAPABlLTnES DATA (FTU-T H.22n 
typcdef struci ( 

DEVCAPS LocaJ. 

DEVCAPS Remote 

DEVCAPS 

im 

^ nCMtt: 

CapaTMaiCapsl: 
ModeslMaxModes) 



// Local device capabilides lisdng 
// Remote device eapibiliites iifrng 
// Comecdvny (nenvork tnterface) capabilities hstuig 
// Number of emiies m 'Modes to Caps' xref tiit 
// Number of enhes in 'Caps lo Modes' aref list 
// 'Caps m Modes- xief list 
// "Modes to Caps* xicf list 



V^CTRUCTimE FOR MEDIA CONTROL DEVICE PARAMETERS 



inx 

DEVICE 



CAPS 



im 

coimefaar* 
MCO BINDING 
HMCO* 

mieo 

} DEVICEPARAM: 



Devkcs; 

DevfMajO^evtcesl: 
Cap: 



nAodioObi: 

nVideoObi: 

nlmigeObj: 

nDattObj: 

pMeoUbelQ: 



pbMco: 
hMco(MaaMcoTypeI; 



// Number of eneapsulaicd devices 

// Encapsulated device chain 

// K.221 capabiiines for VCO devices 

// Number of media cnrt objects concmiy available 

// Number of audio objects cuneody available 

// Number of nwdon-video obieets 

// Number of image objects 

// Number of daa ob^eeu 

// Pirn array of pin to media cnrt object labels 

// Pit » linked lisc of currem media Ctrl objcci btmlinis 

// Pb* m list of handles m all available oedaa ctri objects 

// OeteuU media etrt object handles (reference wim type enimt 



/^CTRUCnjRE FOR CONFIGURATION AND SETUP PARAMETERS 



BOOL 

BOOL 

BOOL 

BOOL 

BOOL 

STATION 

STATION 



tot 
im 

RQBVALUE 
CONFPROFILE 
) CONFICPARAM: 



IsOynaPonaWe: 


// 


IsMuldCoonecabte: 


// 


UMultUnsiamiabie; 
IsResviciBd; 


// 
// 


tsEmntumg; 
LocalSaiion; 


// 
// 


RimwtfStttiDiii 


if 


TcimOttipuiDe vice : 


ft 


CoooeuTimeout: 


ft 


OevieeTimeout: 


it 


DtspaKherRate: 


ft 


Servicefiindwidtb: 


It 


nUnesAvaitable: 


If 


nUnesRequesied: 


If 


ColorKey: 


11 


ConfPnfUe: 


ft 
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STRUCnmE FOR CALL COimiOL PARAMETERS FOR CURRENT CALL 
(ypedvf mnei ( 



4325 



4330 



4335 



4340 



4345 



4350 



4355 



4360 



4363 



4ro 



4373 



4TgO 



43&3 



CALLSTATE 
CONFPROFZLE 
CALLDST 
RESULTCODE 
im 

BOOL 
BOOL 
BOOL 

iiu 
iiu 
ini 
tnt 

UNESTATE 

iiu 

STATION 



Sate: 

CoafPnfUe: 

CallDsc: 

OiscStt&ts* 



URtsmcsd: 
UCaUScwp: 
bCaUiagVco: 
nCosnccooQs^ 




// CaU mcB far enbre mi 
// Hiis coitfetenu prame 
// Dcsniotion for call 

// Ducoanect mm% (when in disconnected sate) 

// Tom aitmber of lines co be used for this cali 

U Tiuc if this call IS resmcied 

// True if this call is seamg up 

// True if this c*U dnrininon is another VCO 

// Number of current connections for this call 

// Total bandwidth uied for this call 

ft Can connect luneout osed for this eaU 

// Timeslott used for this caU fif appticable) 

// Lmesiaie for each line in call 

ft Toial number of stations involved ta conference 

// Pit to list of conference stations (first is local) 



// MULTIPOINT CALL CONTROL PARAMETERS FOR CURREIfT CALL 



MULTICALLSTATE 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 

}CALLPARAM: 



IsConfFoeus: 

IsConfCbair: 

bRcvingConfAudio 

IsRevtnsConfVideo: 

IsRcvingConfDaa 

IsBidcasong Audio 

IsBidcasnagVideo 

IsBidcastingOaci; 



// Vfoilttpouu call soma flags 
// Tnie if scuioa has confemwe locus 
// True if stanon is conference cbatnnaa 
True if siadon is reeenrmg eonferciKs 
ff True if saiion is receiving co nf er ence video 
// Trite if socion is receiving eonfereaee 
ff True if siadon is breadcasang audio 
// True if scuion is braadcasong video 
// True if siadoa is btnadcasong daa 



JSl^f CONNECTTVrTY PROTOCOL PARAMETERS fTTU-T H.320. mJT H^l) 



BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BOOL 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 



UXmongAudio: 
IsXauagVideo; 
tiXtmingDaui ; 
IsReviagAudto: 
IsRcving Video: 
IsRcvingOaa: 
RcvDaaRaie: 
RevAudioMode: 
RcvVideoMode: 
RcvDacaMode: 
XimDittBatg; 
XmAudioModc; 
XntVideoMode: 
XmtOataMode: 
hfcwDuaftaie; 
NewAudioMade: 
NewVUeoMode: 
NewDataMode: 
nMisXtntMode: 
nMiccRcvMode: 



// Title iff 

il True if tnosnuoing video 
// True if cnnsnumiig data 
// True if receivtng aiidio 
// True if receivtng video 
// Tnie if receiving daa 
// Curvem receive cransfer rate 
fi Oifvem receive audio mmlf 
// Oincia receive video Tnotfe 
// Cunem receive data node 
// Qntem mnsnm trusfer rate 
// Ckincm nnsmii audio mode 
Cusrem iruisinit video mode 
// Omens iiauunii dats niHie ■ 
ff Pending mitsfer rate jusi set (pending XnuDaaRaie) 
// tading iudio mode just set (pending XmtAudioMode) 
"^^^ se> (pending XmtVidcoMode) 
// Pending daa mode just set (pending XnuDaiaMede) 
// Number of mtacetlaneous modes set by local stanon 
vV"v " //V:;, . . '"^"■'^ 0' "«U«nBou* modes set by remote sooon 
// List Of maceiUmous mode, set iy local sST 
MiscRcvModefMaiMiscModc): // List of miscellaneous modes set ? local stanon 



BASCODE 
BASCODE 
} raOTOCOLPARAM; 

// CTRUCTURE FOR REMOTE STATION CONTTIOL PARAMETERS 
typedef struct ( 

f22{; IsAtBched; " True if cmd and cvem stream anacbed to . 

UMasKH // True if coniretling remote stanon (master) 

CONTROtMnr^c SST ' " controlled by remou saaon (slave) 

//control mode capability^permissionfUg. 



VCO 
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// STRUCTURE FOR REMOTE STATTGN MONrtORXNG PARAMETERS 



4390 



4395 



4400 



4405 



4410 



BOOL 
BOOL 
BOOL 

bit 

STATION* 
MONITORMODE 
MONTTORMODE 
} MONTTORPAJUM: 



UAOKhed: 

IsMonitonngi 

IsMonnofcd: 

nSCMioii: 

pSaoens: 

Modes: 

Caps: 



// Tme if event nreant aauhed to remou VCO 
// Tme if cnonnonng ii leait one renioi 
// Tme If fflonnored by remote saoon 
// Number of nanons currently moauofed 
// Pit 10 list of sunons curremly momtorvd 
// Monitor mode setong flags 
// Monitor mode capabiliiy/penntssioR Aags 



// CTRUCTURE FOR VCO SYSTEM INFORMATION (VCO PARAMETER BLOCK) 



VCOSTATE 
im 

BOOL 
BOOL 

OEVICEPARAM 
CONnOPARAM 
CALLPARAM 
PROrOCOLPASAM 
CONTRDLPARAM 
MONTTORPARAM 
} VCOFAJUMi 



pVmion; 
RefCoum: 



URttuiy; 
Device: 
Coalif: 
Call; 



Conml: 



// Ptr to VCO label stxiag 
// Ptr to VCO venion sirmg 

VCO global opennonal state 
// VCO reference count of usen 
// Tme if eimiUnng devices 
// Tme if ready to connect to remote station 
// VCO eneapsilated device f«t»w^Ti»r block 
// VCO configuimoon parameter btocfc 
// VCO ctirrem caU paiiraeter block 
// VCO protocol patuneter bkick 
// VCO control conext panmeter block 
// VCO monitoring context panmeter block 
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CLASS VDI 

^1 ^ (Virtual Device latcrteal 

Bdo* II th« decUnaon for the VCO Vinu*i Device Inters CUis. An tnsance ol the VDI class muu comtm. ai a mimmum. all 
of the public member Amcamu use by VCO dtems to esoblish and camrpi muiamedia coniieeaviTy sessions with rriraie saoons 
Thu class must also conam an insance of a VCOPARAM dan smicwre. and the pure virtual member decJaracwns for die device 
comrol member funcm>ns mat provide device suppon lo cbe puMic member funcaon implmenaoons. The implememaoons for these 
pure vimial functions (demarked with the Dev<iatel> symbolic naming convennonj reside m the Ffnfncal Device Interface (class 
POn. -niB consmicmr and desmicur of this class, are protected members, and iheir public interface is via call from 
coBSOUctflr/desmictor in the moiv denvcd class VCO. 



4420 



class VDI: proteaed EVENT ( 



4423 



// MULTIMEDIA CONNECnON SYSTEM INFORMATION 
^30 VCOPARAM VcoPam; 

U INTERNAL DEVICE- lNDEPENDE^^^ MEMBERS GO HERE.. 

4433 



viRixal cann char* GctClaaNaoDeO ( rctuni "VDr; }; 

4440 NETVORX SESSION CONTUOL 

— — — — — — — — — — — 

VDlf cbar« ^XnttFUe • 0 ); 
/* 

USAGE: Consmtct die Virtual Device bnerftce for die VCO. Iniulize VCO parameters and 
secbogs from the spectfted ininalizadon ftle. Setup device-inlependeiit ani code 
objecu used by VCO. Create the de^lt VCO device evem nodfler ani siui the VCO 



PARAM: jjInitFile ..Ftlespcc of Hie diat canuins VCO sianup panms A seangs. 

RETURN: none 

•/ 

4433 vinual -VDIO: 

/• 

USAGE: Destnici die Vtrasal Device interlace. Save currem settings to die inioaiizadon flle. Ctoae 
die vafKMs media cert objects, if open. Delete any noofters aitt saop die VCO dispoBtaer. 
Free all resouicea allocaied by VCO. 

4460 

PARAM: noiv 
RErURN:none 

4463 oubltc: 
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RESULTCODE Optni BOOL .XsBloduDg « 1 ); 



USAGE: PrepAte the VCO for making ctll to remote sunon. IniiUlize til media cut ojeos 
and ifteir ntpporang device control tub-sysiems. Perfonn prclmiinary sub-sysiem 
4470 dtagaosncs and determine tcvel of system funeaonaliiy, 

PARAM: .UBtockmi ...Tnie if call is blocking A will not reiuro unci complete, or false if 

mm-bloeking & rcninu immedtaiely u 'pendtns*. 

RHTORN; Failure 
4475 Success 



TinsdOiu 



DiaibUd 

4480 Memory AltocErnsr 

ReaoiuceAllocErTDr 
IniefiialEfrar 
TunerFatlure 

•/ 

4485 

RESULTCODE Clostf BOOL IsBtockiiit • I U 

r 



USAGE: Sfaittdown die VCO. Slop aU servtcea provided by media ctri obiccB an] close 

their mppomng device eoMral sub-syscems. Free resources allocaied for device courol 
4490 

PARAM: ,IsBtocking ...True if caU is blocking St will not return uniU complete, or false if 

non-blocking St returns immediately as 'pending*. 



RETURN: Failure 
4495 Si 




DiaUed 

4500 MeooiyAllocERor 

Resource Alloc ExTDT 
Insenial Error 



wo 98/09213 



PCT/US97/15018 



-177- • 



45QS 



RESULTCODE Caii( dor' 



BOOL 



jiNinnlMrl ■ 0, 
j}Ntmbcrl m o, 
^IsBlockini « I ); 



4510 



4315 



4530 



4525 



4530 



U5ACE: Esabltsh inicial call n> remote saoon. or MCU: create eonnecDvtty seiuon whose qti>iiiy n 
determated by (he highe«c common denominaior of media ccrl coimecnvicy services, 
as may be accommodated by both local and remow stadoiis. A prefierenee as co the qualify of 
(his imeracuon ts cspiessed by each sauon: subsequemty proceeds aegooaaon. between 
these suitoju. to esablish die most appropriate media device imerconneetjon modalities 
requisite lo best ftiiniing die rcquesu for specific tat nmes connicdngj conference profiles. 

PAKAM: j)Niimtaerl 



^Numberi 

_IsBlockin« 

R£TUKN: Failure 

Pending 

TimadOut 

MustBeOpetied 

Disabled 

InUse 

Memory AllocErrer 

ResoumAilocError 

ImeraalError 

TimcrFatttire 

InvalidOaaType 

NocEoottghfiandwiddi 



...Ptr xo soing with number for line t. null ealli defauh remote scaian. 

...Per to stnng with number for line 2 (if used). 

...True if call is blocking & will not return unnl comptete. or false if 
nofi-blocking 4l reums unmediately as 'pending'*. 



4535 
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4340 



4543 



RESULTCODE MuUlCalK STATION* .pSution, 

MULTICAIXOP Op, 

DWORD >anm • 0. 

BOOL 'UQucry - 0, 
BOOL 



I); 

USAGE; Eanbiith raulapoim call by presennng a multipoim corarol openoon request » (he 

connccavKy sut>-sysiBm. while eunemly connected ro muliipoim comrol unit (MCin. Thii 
runctioii allows a sation to panteipaie in a confeKcice with mere than two confeices. to 
control a conference, and to direct local/conunon medu ctrt to/from conferees. 





PARAM: ^Saiion 


...Ptrio ttiaon descriptor specifying to which station operation applies. 


4350 


-Op 
__Panun 


...Muldpoim call control operauon specifier. 
■ ..Paraineter for speciried opennon. 






...True if call is lo query sub-system for openoon capabUity. 


4555 


.IsBtocktng 


...True if call is blocking A wiU not return until complete, or false if 
non-blocking St mums immediately as 'pending'. 




MULTIPOINT CALL COhrrROL OPERATION USAGE & PARAMETERS 


4360 


< _Op > 


< .Panin > 


4365 


GctNitmSaiions 

GeiScuianCaps 
GfitSmiiotUdctuuy 
...all other ops 

RETURN: Aflusc 


..Ptr to im to receive count of stanons m conf 

...Ptr ID buffer lo hold linked list of STATION records 

...PirtoDEVCAPSfBCOfd 

...Ptr » STATION recotd to rev id of remote station 

...Don't care 


4570 


Soeceat 
TmedCXtt 




4573 


R r^ucnDcnied 
NtnSttpponed 
MimBeOpund 
Dinbled 




4580 
4385 


InUae 

IfUBmalEnor 

InyalkiSniinn 

InvtlldDaaType 

InvalidOpefaoon 

InvalidOpefationNoiw 

ImmUdPaiam 

CaUMiutBeConnccied 

NoCaUForUnsAdd 
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RESULTCODE HangupC tnt oUac • 0 ); 
4590 /• 

USAGE: HanjMip enure call to remote sution. or MCU: selecDvety disconnect specified tine only. 
PARAM: ,nUne • -Number of lines to dtscoaxiect: null bangs up all Imei. 

4595 RETURN: Failure 



TonedOui 

MunBeOpeaed 

Dia>l»led 

4W IncemlError 

InvilidLtne 
CaUMustB eC onnected 
UosUDown 
LincNoiConnccted 

4605 •/ 
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4610 



4615 



4620 



46ZS 



4630 



4633 



4645 



4690 



46S5 



4660 



4665 



EVENT NOTIFICATION CONTROL 

RESULTCODE NewNoUfl«r( HNOTinER& 
EVENTPRCXr* 
void* 
DWORD 



hNatiOcr. 
.pMcmbtr, 
J»ObJtct, 
,£T«itiMask » 0 ); 



J^nlS^v'^d'I^I^^^r " nouficarion object l«t. TT^ noafier « 

lOUttily <*i»btedMoilowiiigcmtKm.*wlmusi be enabled (o nigger. 



...Reference to handle for newty ereaud VCO nonficaaofi object. 
...Pir 89 noufier receiver member to process VCO events. 
•..Ptr B» aoaftcaoon receiver object. 
...Mask specifying events chat will digger nonfter. 



PARAM: ^hNotifier 

j)Mcmber 

jObiect 

.EventMask 

RETURN: Failure 
Success 
RequcstDenied 
DiiaUed 
lovalidDaaType 
InvaiidParam 
Memory AUocEnor 
ImetnalEnor 



MSULTCODE DeleteNoOneri HNOT1F1ER .hNoiilicr ); 

USAGE: Dcteie VCO sigiai and reinovert from VCO Imked object Iwt. 
PARAM: _hNodner ...Hantte to signal lo be deleted. 

RETURN: Failure 



RequeuOeaied 
Disabled 
SnvalidDaaType 
InvaltdNoiifter 



RESULTCODE EoablcNoUnerf HNOTIFXER _hNoUfler, 

BOOL .liEaabled - I ); 

USAGE: Enibte or diaabte signal fmrntnggefing on us spectfird triggering 



PARAM: .hStgDil 

RETURN: Failure 
Success 
Rfidttffiani 
Disabled 
InvalidDaiaType 
iRvalidNoiirter 



..Handle to signal u be enabled or disabled. 

..Tnw enables signal mggcnng; false disables tnggeriiig. 



V/O 98/09213 



PCT/US97/15018 



-181- 



R£SULTCODE SclNotificrTriucrK HNOTIFTER hNotifler, 

DWORD 'ETtntMuk - 0 )• 

/• 

USAGE: Set evems chat will trigger signal 

PAJLAM: _KNocsficr ...Handle to signal whose trigger events will be set. 

_EvemMajk . ..Mask specifying events mat wUl aiggcr stgnal. 



4675 



RETURN: Faihire 
Success 
Disabled 
InvalidDacaType 
InvalidNoiiricr 



4683 RESULTCODE TrlgferNiMincrK EVE^^^lEC• ,p£T«uRe«. 

HNOTIFIER ^hNotifler • 0 ); 



4690 



USAGE: Triggers VCO notifiers senidve to the specifted event, or altemaavely mgger a specific signal. 

PARAM: j)EvenKRec ...Pit to record comaioing event panmesers. 

.liNodfier . . .If specified, indicates specific signal gd be mggered with event, or 

else all nooficrs sensiave to event are tnggeied. 



RETtJRNiFaUuie 
Success 
DiaUed 
InvalidDacaType 
InvalidNoiilier 
^''00 [nvalidParam 
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4705 



4710 



4713 



4720 



472S 



4733 



4740 



4745 



4730 



4753 



CONRGURATION/SETUP COriTROL 



^^SULTCOOE 5ctCMfig( CONnCPARAM* _pConl|| ); 

USAGE: 5ei VCO configunbon daa for miin objeei ind encap«U«ed devices. 
PARAM: j,Config "ftrw record eonuining new configuntion 



RETURN: Failure 
Succsu 
RequestDenied 
Disabled 
InvaiidDiuType 
iRvaiidPanm 
IncenaiErrDr 
TtmerFtthiiv 



RESULTCODE Stor«Coflllg( CONnCPAHAAf jCeaflt » 0 >; 
USAGE: Store VCO configuimnon to backing wore. 



PARAM: jOMtfig • •'^^""rtwnttming configuration w wriiem 

none specified, ihe current VCO config is stored. 

RETURN: FeiUwe 



Disabled 

LnvalidDaaType 

iavalidPanm 

lamalEfTDr 

TanerFtihiie 



RESULTCODE RefrnbCoiifl«( CONFTGPARAM* jjOmfif - 0 ); 

USAGE: Refreahe. cuntm VCO configunnon or configu^on recoM from dut saved ui backing Kore. 

PARAM: jiConfig "[^ «««ve configuraoon read frorn to 

specified, cufiem VCO comlg is refreshed. 

RFnmN:Faitiire 



RoiuescDented 

Disabled 

InvalidDaiiType 

iBvatidParam 

losernaiEfTor 

TonerFailure 
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4760 



4793 



4800 



RE5ULTCOOE SetupAucUoDcvkest BOOL ,IsAlockia( « 1 }; 

USAGE: Invoices dialog box to enible interleave secup of audio devices. 

PARAM: .Isflloctong ...Tree rf call is blockins & will noi recuni uiuU complete: false if 

nonlocking 6l reiurns mimeduuely as 'pendmg'. 



RETURN: Failure 

4765 

Pending 
Rfiduadam 



Not&ippQftBd 

PraeessTerminated 

MustBeOpened 

Disabled 

laUse 

MemoryAltocEiTDr 
ResouiceA!loc£rror 
lotenialErrar 



RESULTCOOE ScttipVideaDcvtces( BOOL _IsBlockiag » l ); 



USAGE: Invokes dialog bos to enable incencave setup of monon-video devices. 

PARAM: ,IjBlockinf ...Tree if call is Mocking^ will not remra unol complete; false i/ 

fioo-blocking St remms immediately as 'penling'. 

RETURN: FaUure 
Pending 



4785 



4790 RcquescDenied 

NotSupponed 



ProoessTcmuaaced 

MustBeOpened 

DiaUed 



Memory Alloc Error 
ResourceAllocEnor 
liuemai Error 



RESULTCODE 5citfplBiafeDevices< BOOL ^IsBlocUag « 1 ); 

USAGE: Invokes dialog boa to etable tmeracdve icojp of image devices. 

PARAM: _IsBlocking ..-Tme if call is blocking & wUI not leture umd complete: h^st, it 

non-blocking 4l retunu immediaKly as 'pending'. 



RETURN: FaihiK " 
Success 



4810 



RequestOenied 

NotSupponed 

PfoeessTerramaied 

MttscSeOpcned 

Otttblcd 

ZttUae 

Memory AllocError 
ReaouiceAlloc Error 
4820 buerraJ Error 
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4823 



4830 



4833 



4840 



4843 



RESULTCODE Scmpi>aUl>cirtctsr BOOL .IsBlocUiif m | >* 

USAGE: l^avto dialog bo. n enble intencavc «tup of diu conwcnvity tnd necwork «di«r 

de^(Ne««,rk Interface Uiu«». « well „ allow configuration of sy,^|/o1^ Setup 
of«ewfOrtE(>roiocolsupponMftw»refKMleiher«. « poiu. aetup 

PARAM: JiBtocking ...True if caU i, blocking & wUl no, remm uniU compieu. or fkUe if 

RETURN: Faihiie non^rtockmg & renmu tnunedi«eiy « -pending-. 

Success 



Re«|tirff Denied 

NofSupponed 

PnceuTenninaied 

MunBeOpened 

OittMed 



MemoryAllocEtTDr 
RcaourccAllocEnor 
InserealErTor 
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KfEDlA CONTTROL 



4830 



4855 



4860 



4865 



4870 



4875 



4880 



4885 



4890 



4895 



4900 



4905 



4910 



R£SULTCODE MMUaCoiitniJ( MCO_TYFE 

MCO'SETTING 
DWORD 
BOOL 
BOOL 



.McoType, 

^Panm « 0* 
.IsQucry m o, 
ItBlockiiif « 1 ); 



USAGE: Accfttt «erv,ce provided by enapsuUied medu conaol devtee by presenong media ccrl 
eemol teauig co physiul device comroi sub-synem. 



PARAM: .McoType 
Scning 

_UQucry 
^ItBlnching 



...Sp eci fic media cirt object type for openoon. 

...Audio-video^u semng consam specifying requested service 
desifcd from objeci. 

. ..If required, provides paruncter necessary lo fully specify request to 
media Ctrl object. 

...True tf call is 10 query sub-syseem for openoon capability 

...Tfue if call is blocking A wilt not return till complete, or Olse if 
non-btocking St remrns munediaieJy as 'petting*. 



MEDU COffTROL OBJECT SETTINGS & PARAMFTERS 
< ^SeiDng > < _Puim > 

BASE OBJECT SETTINGS: 
NoSetting ...Don't care 



Close 



Disable 

Oa 

Off 

ABMbTo 

OetachFtom 



...Don't care 
...Don't care 
...Don't can 
...Don't care 
...Don't care 
...Don*c care 

..^CO type to which lvalue MCO wilt be i 
...MCO type to which tvahic MCO wiU be 4 
...Don't care 

...Pit to Ubel of MCO to add to lvalue MCO to create eomposue 
...Pir to Ubel of MCO to remove from lvalue composite MCO 
...Value selected from one of < MCO_COMPTYPE > 
...Adr of Pir that wiU peim to pafamecer block appropnate 
for the lvalue MCO: that is, it wiU be pcrio oi» of: 

< MCO.AODIOPARAM > 

< MCO.VIDEOPARAM > 

< MCO.IMAGEPARAM > 

< MCO.DATAPARAM > 

.I^Mni > 10 whoie capability is directed such inquiry 

MEDIA COKTKQL OBJECT SETTINCS PARAMETERS CONTINUED 
MOTION-VIDEO SETTINGS: 



AddToCompostce 
ReiBOveFramComposite 
SetComposiieType 
GefStaois 



ScfCotorfcey 
AasigoWtDdaw 
UnanignWodow 
RAStaeWtndow 
SdStRBebOn 
SecSffeKbOrr 
SetlmagfiType 
FfKsxe 
Unftceze 

SeCPnipuraonalOn 
SctPiQporaonalOfr 
SeiVkleoframeSize 



... < RCBVALUE > (cast to DWORD argument) 
...Pit 10 unasugned wmdow's dau ofegea 
...Pit to previously assigned wmdow s data obiccf 
...Ptr to previously assigned window's daa obyeci 
...Don't care 
...Don't care 

...Value selected from one of < IMAGETYPE > 
...Don't care 
...Don't care 
...Don't care 
...Don't care 

...Vahw seJeeied from one of < VIDEOSIZE > 
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4912 



4920 



4925 



4930 



4935 



4940 



4945 



4950 



4955 



4960 



4965 



4970 



4975 



IMAGDIC SETTINGS: 

AftugnWtndow 

UnusifnWindow 

ResizsWifidow 

SeiSixeieltOn 

SetSiRicliOfr 

SeUmagQType 

SedougeMetnc 

SetPuelWidib 

SecPudHfiigbi 

SeiPixelOeiKti 

SctFhysicAlWidtta 

SetPhyiiealHcight 

SetKotzPijuKSnsui 

SeiVenPixetOrigm 

ScKHofxPliysicalOrigin 

SetVenPbyaicalOrigin 

SetHonPtxdDefisiiy 

SetVenPUelDcostty 

SeibtugeCQinbioeType 

AUDIO SETTINGS: 

SetAudioQuality 

SyncbToVidsb 

UnsynchFiomVideo 

FchnCincMlOn 

EdKOiicaiOff 

SetflTMFDusigion 

LocslDTMFPuUe 

H cnwtf OTMFPuhc 

DATASETnNCS: 

SdSjmcXrerMode 
SctAsyncXfeiMode 
SedUsoieifldMode 
SeiUnRsincteilMode 



RETURN: Faihtn 



TisMdOut 



NoiStippoiiBd 
PfOGCuTcrmiiutBd 



laUtt 

MeoofyAUocError 
ResottcceAllocErrar 
IntenBlEnor 
TinrnFuhiK 



lavaiktDeviccRcann 

InvmlidOpefiBoiB 

tnvalUOpenooiiNaw 

InvsUdOfafcet 

InvalidScoiiig 

InvilidPinm 

NocEnougtiBandwidUi 



...Ptrtounassigned window's dan objeei 
...Pxr to prevtously tssrgned window's daa ota^eei 
"Pxr ID pnvtousiy auifited wii^w's <taa obieet 
...Doa'tcuQ 
...OoB'tcire 

..Viiue setected fram one of < D^OETYPE > 
...Vahtt selected rram one of < IMAGEMETIUC > 
...Integer pixel count 
...Inieger pixel count 
...lUBgeff pixel couni 

...Imeger unia xccoidiog to curceni metnc 
••™f«' unitt according to cunem metnc 
..Imeger pixel count (offset from left) 
..Izoeger pixel count ioffset ffom 8ip» 
..Integer units according to current mecnc (offset fram lcfi> 
. .integer untts sceerdtng to cuirem metnc (offset fram cop) 
..integer pixel count accorduig to units per current metnc 
..integer pixel count according to uiuu per current metnc 
-Value setected from one of < IMAGECOMBINEmE > 

..Value selected from one of < AUDIOQUAUTY > 
..P» to video obi bbel to whtcb lvalue obj wdi sywh 
..Pir m video obj label fram which lvalue obi will be unsvnrh 
..I3on*i care 
..Don't em 

"^^y^ ™»ber of mtihseconds for ducaoon 
..teger tvpimnung keypad buizon 
..InsBger representing keypad butam 

..Vthie selected from one of < DATARATE > 

..Don't caie 

..Don't caie 

..Don't ears 

..Don'tcaie 
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4980 



4985 



4990 



4993 



5000 



RESULTCODE 5ctDcraultMeo( MCO.TYPE .McoTypt, 

com char* "pMeoLabeJ ); 

USAGE: S« the VCO's default media ccrl object for the speciAed objeci type. 

PARAM: _McoType ...Type of ntedia ccd object to which liefauit medii ctrl object wiU be let. 

j)McoL8hd .,.Pff to Ubel for media ctri object to set as default. 

RETX/RN: Failure 
Success 
Redundant 
NocSupporud 
MuitBeOpened 
Duabted 
{aUie 

IntemalEfTor 
InvalidDatiType 
InvaJidOfaject 
InvaitdSeodng 

•/ 

RESULTCODE 5clI>efaultMco< MCO TVPE McoTypc, 
HMCO ~tiMce>; 



USAGE: Set Che VCO's defauit media ctri object for the specified object type. 

PARAM: _McoType • -Type of media Ctrl object to which de&iiU media ctrt objeci wtU be t 

J*^^ - Handle of media Ctrl object to set as deteilL 

RETURN :Faihtre 

5010 



S0t5 



5020 



NotSupponed 
MustBeOpened 
Dittfaled 
loUie 

InBunalEnor 
InvalidDataType 
ImraiidObjea 
bnraltdSetEiAg 
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5025 



5035 



5045 



5050 



5035 



5060 
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PROTOCOL MANAGEMENT & CONTROL 
RE5ULTCODE 5etCoDfPRifac( CONFPROFILE .Pronie ); 

e wun oui leieca device modes moic tpprepnate to the specific caU type. 



PARAM: ProfUe Tw«.-* * 

. . .Type of conference profile desired. 



RETURN: FtUiue 



NotSupponed 
Diabled 



RESULTCODESetModes(BASCODE* jModelin, 
5040 /. ^ _IlM0€l«-'l); 

USAGE; Aoempi to set H.221 dev«e modes for eail i„ p^grw. 
PARAM: jiModeUsi -Pff to list Un»y) of H.22i mode consams to set. 

.aModes ...Number of modes in list. 



RETURN: FiihiR 
Sitoccu 



ImefBilEiior 

InvaiidDtaType 

InvalidMode 

tnvaltdPatun 

CiUMusiBeCannected 



USULTCODE SemlCftv^; 



PARAM: none 
RETVRN:Fiihi« 



5070 



MusiBcOpeiKd 
DteUed 



LinebOown 
UneNocConneciBd 



wo 98/09213 



PCTAJS97/15018 



-189- 



3075 



5093 



31Q0 



510S 



sno 



3113 



3120 



5123 



RESULTCODE VertfyBaoiividtbf BASCODE AtidloModc. 

BASCOOE 'DauModc 



USAGE: OetenntRC if call has sufTicieni bandwidih to suppon me specified eombtiaoon audio i 
daa modes. — «"— 

PARAM: _AudioMode ..Rcqwcsicd H. 221 audio mode. 

_DaaMode -.Aequested H. 221 dan mode. 
RETURN: Failure 

5083 



NotSupponed 
MimBcOpened 



UttcnialErTor 

5090 TinerFaihiR 

UndefinedBfsult 

InvsUdMode 

CaltMusiBeConneetBd 



RESULTCODE SctDerieeTbBcami DWORD _Ms«c ); 



USAGE: Set de&uit connecdoo osneouc vUue for encapsulaied network inserfaee in tenns of how fams 
It will wait for a response from die network. 

PARAM: _Msec ...Timeout value in nulliseconls. 

RETURN: Faihue 

SUQGCSS 



Dinbied 
IntBiittlEnor 
TilDerFatttm 
InvaiidPanm 



RESULTCODE SeiCoiiBcctTlmMid( DWORD Msoe); 



USAGE: Set dehulf connecdon timeouc value for call eonmriler in terms of bow tons n wiii wait for die 
emiie call connecnon T^irnrr to ccm^ilete. 

PARAM: _Msee ...Timeout value in mUliseconls. 

RETURN: 



Dtsabtod 
InvalidPinm 
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5130 



5135 



5140 



5145 



5150 



3155 



5160 



5165 



DATA EXCHANGE CONTROL 

RESULTCODE TramferBulTcH BYTE* 
im 

caoft char* 

BOOL 

BOOL 



jtMcoLabcl • 0. 
.UQucrjr ■> 0, 
.IsBlecklog m I ). 



USAGE: Tniufer buffer to or from 
PARAM: j)fiur 

.nByies 

.pMcoLabel 

.IsQuery 

.IsBlocking 

RHTURN: Failure 



TUmlOui 
Raqn>rnlVnfed 
NoiSapponed 
MnscBdOpened 



Memory AllodError 

ResouircAUocError 

InerealEmr 

InvalidDaaType 

InvalidObjccc 

InvalidPanm 

CaUMuscBeConneciBd 



remott mnon. depending on the sigoai type for the ol^ 
.. .Ptr to data buffer to transfer. 

• •.Number of bytes to nnsfer. 

...Ptr to UfaeJ for media Ctrl data object, or miil to indicate defauJL 

• .Tnie If call « to query jub-fysumi for openaon capabUity. 

nonlocking Sl reiunu immediately u "peiKttngv ' »' 
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3170 



3173 



3180 



3185 



3190 



3 193 



3200 



RESULTCOOE TransfcrObjcctC MCO^XTERODJ XTerObi* 
XforObJect- jiXftrObj, 
CUBA clur* jpMCOLabel > 0, 
BOOL IsQueiy » 0, 

BOOL UBlocUttc " I )i 



USAGE: Transfer daa ofajecc to or from remote stuun. depenling on the signii type for the object. 



PARAM: ^XfciObj 

^XfefObfect 
_pMcoLabcl 
.IsQuery 
^IsBlockmg 



RETURN: FailuR 

SUOBCU 



TinedOui 

Re^uestDettted 

Noclinptemeitted 

NocSupponed 

MnflBeOpened 

DiaUed 

InUsc 

MetaoiyAilacEfTor 

RexxtrccAUoc Error 

littBiittiEfior 

InviiadDaaType 

InnlidObjeei 

InvalklPanm 

CiUMusBeConnected 



...Type of object to nhsfer. 

...PiriD (he object's descriptor object containing spectftc informaiioii. 

...Pir to Ubej for medu Ctrl data object, or mill to indicate default. 

...True if call is to query sutvsystem for operaoon capabtlify. 

...Trtie if caU is blocking A. will not return until complete, or false if 
non-blockxng Sl mams immediauly as 'pending'. 
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TERMINAL SERVICE COmHOL 



5210 



5213 



5220 



5225 



5230 



5240 



5245 



RESULTCODE ToTcnunaU char* _pFnii. ...); 

PARAM: j»Fmt -Pir fo fonittt Krmg. 

"Variibie number of text and data args. 

RETURN: Failure 



RequestOemed 

Disabled 

ZaUse 

InvaiidDataType 
InvalidFatam 



RESULTCODE rTaTcnnmaK char* jiWhxl, 

void* j>ArfLlat ); 



USAGE: Write daa lo the VCO tcraunai OUTTtJT nrm - < 

10 anumenu "^ur pan opaonaiiy using format saing and U« of pn 



101 

PARAM: jFmt - Pirto fomut imng. 

™^ j>AisUsi . ..Pit to lisc of pin to arg nnngs. 

RETURN: Failure 



RaqucstDciued 

Disabled 

InUu 

InvaiidDaeiType 
lAvalidPaiam 
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5250 



5265 



RESULTCODC FromTennmaif char* jiRnt, 
/• 

USAGE: Wrice daa to the VCO lermuai INPUT pon (VCO conunand imeivreiery ooQOiuUy usiag 
fonnai smitg tnd list of pen to arsuraeitti. 

PARAM: _pFmi ...Ptr ta fonnit string. 

...Vahabte mimber of teu anJ daa irgs. 



5255 RETURN: Faiiure 

RequestDciued 
DisaMed 

5260 InvalidOaiaTypc 

InvalidPanm 



RESULTCODE vFromTcnnmaK char* jWmi, 

j)Ar«Un ); 

USAGE: Write data to the VCO tenniBal INPUT pon (VCO command uuerprecer) opaonally using 
fonrnat stnng md list of ptn to arguniBms. 

^270 PAAAM: jiFmt ...Ptr to fomau siring. 

jiAiiUst ...Pit to list of ptrs to irg smngs. 

RETURN: Faihifc 
5275 SuGceu 

RequestOented 

Disabled 

InUse 

InvalidOauType 
5280 InvalktPanm 
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S28S 



3300 



33QS 



S3U 



RESKJLTCODE ActachTcnnToNotincrt HNOTZFIER .hNotlfler ); 

USAGE: Aracii stcul » VCO tenmiul ouipui device in order to dtreci cemuail OirmJT Don text 
nxiBtm lo the assocaaced Norificr Receiver Object (NRO). 

PARAM: ^hNotirier ... Handle to signal to attach 



«90 RETURN: FaUure 

Sueceu 
Redundant 
RequesiDeDied 



3293 inUM 

InvaltdNoiirier 



RESULTCODE AtUchTcRDToFUeC char* _pFUcspcc. 

BOOL .IiAppcnd' » 0 ); 

USAGE: Attach ftie as VCO tenmnai output device tn order to dtrcci tennmai output pen text nream 
10 a ipecifie fde or file system device. a* sumn 

PARAM: jjfilespec ...Pit » file specification of file to atach. 

_liAppeod .„Tiue if new leu to be appended to current scrum position: Use if 

stream posioon to be reset ai ome of attachencnt. 



ReqitestDented 



RETURN: Failure 



3313 



3320 



IttUse 

InvaUdDaaType 

•/ 

RESULTCODE AtUcfaTcnnToSlrami tmm« _pScraiD« 

BOOL _UAppcBd a 0 ); 

USAGE: Aoaeh system daa sutam as VCO terminal output device m onlcr to direct ternunal output 
port text stream m specific data stream cnaty. 

PARAM: ^neam ...Pit id stream to aoach. 

_lsAppend „.Tnie if new text to be appended to current stream posidon: false if 

socam position to be reset at ome of acochmenL 



3330 RETURN: 



3333 



RequessDenied 

Disabted 

InvalidDaaType 
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5340 



S343 



5360 



RESULTCODE AtUchTermToMeo^ HMCO _bMco. 

aOOL "isAppcttd » 0 ); 

/• 

USAGE: Atuch meda cirl object ts VCO tcnninaJ output device in order (o direct temiuul output 
pon text nream to media cui object suppomng dau mnsfers. 



PARAM: hMco 



..Handle to mcciia cnl object to aiocii. 



_IsAppefid .. .Tnie tf new text to be appended to cunrm stream posmon: false if 

scream posioon to be reset at lime of acocliraeju. 



RETURN: Failure 
5350 Success 

Redundant 
RequestDenied 
DisaMed 
InvalidDauType 

5355 •/ 



RESULTCODE DcUcbTermFram( TERMODEV OutputDev ); 
/• 

USAGE: Remove previously aoached signal. fUe. or data stream from the nnmaal ouspai pon. 
PARAM: ^OutpuiDcv ...Terminal output device from which to detach termmal output. 



RETURN: Failure 
Success 

3365 Redundara 

RequestDenied 

Disabled 

InUse 

InvalidDataType 

5370 •/ 
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3373 



SYSTEM INFORMATION CONTROL 



3380 



53S5 



BOOL IsIUadyOi 



USAGE: Returns mie if VCO is ready lo nuke imoaJcaU 



PAOAM: none 

RETURN: True 
False 



to remote sution or multipoint control unit. 



5390 



5393 



3400 



540S 



S4I0 



3413 



BOOL IsCaUSMpO; 
/• 

USAGE: Remrmaue While call is letnng up. but not connected. 
PARAM: none 

RETURN: True 
False 

•/ 

BOOLbCailO; 
/• 

USAG& Rcninutiue while call tt fully connected to renwteitanon. 
PARAM: none 

RETURN: Tnie 
False 

•/ 

BOOL IsMttlUCaUO; 



USAGE: Returns mie whtte connected to more than 
PARAM: none 

RETURN: True 
False 



one rvmoce station or nuiliipoini control unit. 



3420 



3425 



BOOL IsRemoltVcoO; 

USAGE: Reoims mie if 

PARAM: noiK 

RETURN: True 
False 



is a muliipoim control unit. 



3430 



3433 



BOOL bRenouAOMbcdO; 

USAGE: Returns tme if remote «aoon VCO command a«l/or event «xeam is accesstble to local i 
PARAM: none 
RETURN: True or Fahe 
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S4S0 



5475 



5480 



BOOL IsMuHilBSUntiBtcdO: 

USAGE: Retunu mxe tf this VCD is running with more thui one msance. 



5440 PARAM: none 

RETURNrTrue or Filie 



3445 DEVtCEPARAM& GctDcvkePanmO: 

/• 



USAGE: Retunu reference lo sadc buffer conaoung copy of VCO device parameten. 
PARAM: none 

RETURN: Reference lo copy of VCO device ptnmeter block 



CONnCPARAMA GetConfisPanmO; 
5435 /• 

USAGE: Reoims reference id sattc buffer containing copy of VCO config parameien. 
PARAM: none 

5460 RETURN: Reference to copy of VCO configureaon piramecer block 

•/ 

CAIJLPARAM& CetCAUPanmO; 
/• 

5465 USAGE: Remras reference to static buffer conaining copy of VCO caU paninecers. 

PARAM: none 

RETTJRN: Reference co copy of VCO caU parameter block 

5470 •/ 

PROTOCOLPARAM& GeiProtocolPatnmO; 
/• 

USAGE: Reoxnu reference lo sqeic buffer conaining copy of VCO protocol paxafneten. 
PARAM: now 

RETURN: Reference lo VCO protocol patameter block 

C0NT110LPARAM& GdCoBtrolPftmO; 
/• 

USAGE: ReniRts reference to scabc buffer comaintng copy of VCO canml eoniext panmeten. 
5485 PARAM: none 

RETURN: Reference co VCO conmsl coniext parameter Mock 

•/ 

MONITORPARAMA CetMosharPantnO; 
/• 

USAGE: Remms reference lo snac buffer conaining copy of VCO monitor context parmmesn. 
PARAM: none 

5495 

RETURN: Reference to VCO monitor coraexi parameter block 
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VCOPAXAMA CctVcoParamOi 
3J0O /• 



5503 



5510 



5333 



5540 



5545 



USAGE; Reouio icfeccna lo saoe buffer comoong copy of .|| VCO paruieon. 
PARAM: none 



RETURN: Rcfcrcne. u> VCO iyrnem urfomuwn p.»m„.r block 

MCOPAIUM& CdMeoPaniiM MCO.TYPE .UcoTrpc )i 

USAGE: Re«.m, re.e«nee a, .«« buffer eonaimng copy of medi. ctrt p«M»„, Wock. 
PARAM: .McoType -Type of n«lu eul object 

5515 ., "^"^ block for spec.f«dnK^^^ 

MCOPARAM& CctMcoParanU HMCO ,hMee ); 

5520 "'«»«'»^«'»o»«M»ing copy of n«di.c«p,nn««rW^^ 

PARAM: .hMco ..Hindle o medi. crt objeci 

RETORN: Rele»nee » m«ti. cot ob,e« p«™e«r block for .peeUicd medi. c»i objec 

5523 

VmEOSEE C«V««^< MCO.SIGNALTYPE .SitfTyp. - Siffalte ); 

USAGE: RcDOT VKie. tnm, .ue for def»di »ideo object of specified «ig„l n^. 
PARAM: .Si.TVpe ...Vid«, .ig«, u, f,, 

RETURN: Eminiented video frame size vthie 



AODIOQUAUTY C«AudteQi«Jity( MCO.SIGNALTYPE ^Sl^ype - SignalDrt ); 
USAGE: ««««« quality of default audio obiect of ipecr^dsign^ 
PARAM: .Sigiypc Audio lignai lo c«nunc for quaiicy 

RETURN: Enumenced audio qualify vaiue 



G«|fI231ModcLAbd( BASCODE Mode)- 
G«lU221Ca|kLabcK BASCODE CmpU * 

^ y Hrm tirodal ah>l f RESULTCODE RemttCodt )' 

cwtelttr-CetETeatLabeM EVENT Evoi ), " 

5550 COM char- Gct r alLSto u i^baK CALLSTATE * CaUsSt 

c«W char* G*tiW«fioaFiim»^okeaUbe« (nt MtdiaClrrTokta I- 
«0M char* GetMcoLabell HMCO hMco ); " »' 
CM char* G«tMcoi,abeKMCO TYPE McoType h 

3333 coiw char* C«tSuteiLabei( BOOL .URttBoteSuaoi -T^ 

USAGE: Reoire ptr to text label tpecified uate or connaiu iiem. 

j^gp PARAM: The specified iiaie or consan 

RETURN: Ptr to consom string if irgumem valid, else nuil 
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HMCO CciMcoHaadlcC const char* jiMcoLsbci ): 
3565 /. 

USAGE: Reoim lundle to mcda Ctrl object specified by ics label. 
PARAM: ^pMcoLabel ...Ptr to Ubel to medsa ciri ob;ect bbel. 

^™ RETURN: Handle n media Ctrl object specified by the label, else null if no sucb media cirl object round. 

HMCO GctMcoHaiidle< MCO TYPE McoTypc ); 
/• 

USAGE: Remm handle to media ctil object specified by lu type. 
PARAM: ^McoType ...Media cirt object type. 

RETURN: Handle to media art object specified by the type, else null if no such media Ctrl object found. 

RESULTCODE UstDericeParamO; 

RESULTCODE LtstConfigParamO; 

RESULTCODE ListCanParamQ; 
5585 RESULTCODE UstProtocolPanniO; 

RESULTCODE LiitModcCapaXRc&O; 

RESULTCODE UstMCOBinditttsO: 

RESULTCODE UstMCOsO: 

RESULTCODE UstNoCiflersO: 
5590 RESULTCODE UstCammmadaOi 

RESULTCODE UstTcrmiDmlOutpyttO; 

RESULTCODE LlxtCoainrcciO: 

RESULTCODE L faiCcmcimMnCapsQ; 

RESULTCODE UstMutaCaUStatciOi 
55«5 /• 

USAGE: Ouqna fonnaBBd teu Usdng for specified panmeier groups 
PARAM: mme 
5«» RETURN: Fathire 

•/ 

RESULTCODE LixtMcoCapK MCO TYPE McaTypc* 
MCO^SETTING 'Setting ); 

USAGE: Output formaoed teat listing of capabtltdcs for specified default media Ctrl object. 

PARAM: _McoType ...Specific media Ctrl object w addicts 

5oiu 

_Seani| ...Audio-video-dafa xetnng constuu specifying requested service 

desired from ofarreci. 

RETURN: Faihuc 
5615 SiiGceis 

InvaiidObject 
InyalidSening 

•/ 

RESULTCODE UstStationCapsi STATION* _pStaUoa « 0 ); 

USAGE: Output farmaiurd leat lisdng of H.221 capabilities for specified soinsn. 

PARAM j>Saiion ...Ptr » staoon descriptor (0 remnu caps for local saoon). 

5qZ5 

RETURN: Faihire 



InvaiidStaiion 



5C30 
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Sd35 



5640 



5645 



5655 



5680 



5685 



VIRTUAL CONNECTION OBJECT CONTROL 



RESULTCODE EaibicVeoC BOOL .XsEoablcd • I ); 

USAGE: Sei VCO enible fUj lo ime or ftise to ch^gc «:ce«ibiliry of VCO. 
PARAM JsEaablcd .-Tnie if VCO u, be c«bied: fa|« to disable. 



RETURN: Failure 
Success 



RESULTCODESeiVeoExcepcModeC EXCEPTMODE Mod. - ExeptModeUser U 

USAGE: SetthecummVCO«weptionh»ndiingmod«lio^^ 
PARAM: .h4odc "Ewcpoon handling mode desired. 



RETURN: Failure 



RequescDenied 
NocSupponed 



^ RESULTCODE Set VcoTracaMcdof TRACEMODE _Modo - 0 ); 

USAGE; Set die cuftwii VCO trace output inodaltiy. 

PARAM:, Mode -..Toce output mode desired. 

RETURN; FsiUire 
Sueecu 
Rfidundauu 
RequescOenied 

5670 N«Supponed 

RESULTCODE £iufakMttUiCaI10pi< BOOL _IsEnabled - 1 ); 



PARAM: ftPifltMfd -r-^ ^ . 

_u«HH« ...True If mulopouu control operaoDfis to be enabled: fuse o disable. 

RETURN: Faihue 



Redundant 



NotSupponed 
MusiBeOpeiKd 
Otsabted 
IntentalEfTor 
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R£5ULTC0DE EiubUIMspatctacrf BOOL IsEaabltd > l )• 
5690 - /• - • 

USAGE: Enable or disable die VCD dupaoclier. 

PARAM: _UExaWed -Tnxc if VCO dispatcher opcnnng; (liie if noc. 

5693 RETURN: Fathire 

SlfTCCTI 

Redundini 
biUse 

Timer Fiihire 

5700 •/ 

RESULTCODE QucucEventC EVENT |d, 

DWORD "PbwiI, 

™. WORD "P««m2, 

^ STATION* IpSuUoo - 0 ): 

USAGE: JnseiT event into the event queue. 



3710 



S713 



5723 



PARAM: Jd ...Event tdemifier. 

_Panin I . . .Fim evettt fsamaeter. 



Pmal 



..Second evens (taimraeter. 

-Ptr 00 moon descnptor (nuU indicates local siaixoiU. 



RETURN: Failure 

QueueFuH 

^™ MttnoryAllocError 

IiivaiidStaoon 
invlidPattType 
KnvalidOperuion 



^SULTCODE 5etDispatchcrRate< int .Msec « DefniiOisintcberRBle U 
USAGE: Set die ntc at which events are dispatched from die event i|ueue 
5730 PARAM: .Msec ...Dispatch rate w miUisecondi. 



RETURN: Failure 
Su 



573S TbneiFaihue 

InvalidPanm 
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5740 



574J 



5750 



5755 



5760 



5765 



5775 



5785 



5790 



5795 



RESULTCODE UpdatcCapsUstC BASCODE _Cip, 

USAGE: Add or remove Ufabiltty lo/frora local capabiJiiy 
PARAM: ,Cap .-Cipibiiiry camam. 

-P^^*P*^* • - Pir to label for upabUicy. 

JsNewCapi ...jnie if new cip, „ .dd co list: false if cap » n^move. 

RETURN: Failure 



Redundant 
RequeitDenied 
InvalidDataType 
InvalidCapability 
InvalidPanm 

•/ 

RESULTCODE UpdateModeC«piXRef( XREI^ jOOUf. 
/• BOOL .IsNtwXRef » t ); 

USAGE: Add br remove mode^api croti-refetence n/frotn local li«. 
PARAM: jiXRef ...p„ ^ mode^ crDsa-refcr^nce record. 

.IsNewXRef ...Jme if new reconl co «ld: false if rtcort to remove. 

^™ RETURN: Failure 

Suceeu 



RequettDemed 

ImnUidOaaType 

IfivalidCapabUiiy 



R£SUtTCODEEaiiCantrolfEMUCONTROLCP _Op, 
57B0 /• STATION* jiStHtoo - 0 ); 

USAGE: Present emulation control opeimoon lo a VCO. 
PARAM: _Op ...Eimilation connol opeimoiu 

-^"^ * <l«enpttir <nuU tnlicates local uadoal. 



RETXniN; 



NocSupponed 

ImenaiEmr 

tnvalidOpentton 

InvalidOpenoonNo 

InvalidSaoon 
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RESULTCODE AlUchToRcmoteVur BOOL .UMoaiiorOnty 



5830 



5825 



2840 



/• 



BOOL .IsBtocUai - 1 ); 



1. 



USAGE: Cam *««^ « the comnuiKl and/or cent swam of the «mote sunon. lYu. acaon ii My 
possible If Che remoce suaon is niniung . VCD for >u mulumedu connecaoo lervKes. 

3805 pARAM: JsMoni«K>nIy Jnic if rc<me« « oniv „ monitor me rtmoie VCC, evem ««ain 

and not its conunand scream (for the purpose of mascenng u). 

.hBlocJong ...Tnie if caU ii Wockmg 3, wiil noc return unnl complete, or false if 

5810 RETURN: F«mre "on^locking & returns unincdutely as 'pe.«*mgV 

Success 
Pending 
TimeMuc 



^815 Re^scOeoted 

NocSupponed 



ProcessTermmaied 
MustBeOpened 



tnUse 

ImemalEmir 
UndeftnedResul c 
Cal IMusiBeConneetcd 



I^SULTCODE DeUehFnanRcnioceVcoi BOOL _UBlocking • I ); 

USAGE; Discartl access gaintd to coinmand and cvemsoeim of retnoa 

PARAM: .UBlocking ...Tnie if call is blocktag & will not nmm tinal complete, or ^ if 

RETURN: Failure noM.locking A rtnims immeduteiy as 'pending-. 



Sl lf ff I S 



5835 TunedOui 

Redunduii 
RequcstDenied 
NotSuppofiBd 
PioeessTeniunated 
CapsMe 
Incapable 
MustBeOpened 
IntetittlEmir 
TinerFatfatR 
UndeftnedResilt 
CaOMttstBcCanneciBd 



5850 RESULTCODE SetVcoCaniralModeC DWORD .ModefUg, - MsAer >; 

USAGE: SetttiemodeofVCOcomnilsothM^^^ 
vuu, as coongured. 

PARAM: ,ModeFligs ...VCO comnii mode flags selected {mm < CONTROLMODE > 



RETURN: Faihirt 



5855 



RequestDenied 
3800 tnaraalEfTor 

InvaltdOpemion 

InvalidOpennoRNow 

CaUMustBeConnecced 

•/ 

586S 
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RESULTCODE S«tVcoMawU.rMode< DWORD .ModeFUg, - MonModcUcI ); 

PARAM: ModcFUg, ..,VC0 n«,n„or mode «iected from < MONITORMODE > 

RETURN: FiUurc 
Success 
Redondim 
RcquestDcfued 
lmenal£iTor 
ImnlidOperibon 
InvtlidOpentionNow 
CaUMusiBbConnccsed 



5873 



5880 



R£5ULTCOD£ SelStaUonlabeU tbar* jiLabcl, 

5883 y ^ J>N«niii 
USAGE; Sec label for the locil sooon. 

PARAM: j,Ubei ...Pit » suiion tabel. 

'™ RETVRN: Failure 

Success 

ImralidDataType 
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5893 



3900 



ALL MEMBERS BELOW ARE TO BE ACCESSED ONLY FOR THE EMPLEMFNTATtnM " " " * " 

OFTOE above.de™ed Ptmuc^ FUNcnoNST^S:? cS;:,^^ 

I^^raFACE COMPONENT OF EACH VraTUAL CONNECTION OBJECT "^^^"^^^ 

^"CATIONS. 

private: "■•■■■■■■■"-•"■•■--tB«»«i. 



typedef emitn { 

5!2fi«« " »«"P component 

A S^^? J^^^ » // Add or rermyve device captbduy 
5910 SS^^^!I^»v« operations to c<mn«r to remote VCO 

VendcrSpccificOp, // Vendor-ipccific device eoncroi openooiu 

5913 lOComrolOpEnl 

) iOCONTROLOP: 



, PURE VIRTUAL DEVICE CONTROL MEMBERS 

3«0 -..../ 



virtual RE5ULTC0DE DcTOpen( BOOL ^UBlockiag • 1) « 0; 

,925 ?^ e««P«»*teJ devicej. load and inidaltze OEM device eontiDl ^hwzn and MO 

driven; pnpare VCO to place outgoing, or receive iticoming call. 

PARAM: .Isfilocking ...True if call is blocking A, will not reum unol complete, or false if 

non-Mocking returns inunediatety as 'peiviingV 

^930 RETURN: Faihire 



3935 



TinedOut 
Memory AllocError 
ReioufceAilocError 
IfuemalErrar 
TtnterFatUire 
InvaitdOeviccRenim 

•/ 

5940 

virtual RESULTCODE DevCloMK BOOL .tsBiocking » 1) » 0; 

USAGE: Close eneapsiiiaied devKes. unload OEM device control sofrwaie and driven: stnudown all 
syssema reUisd to establishing calls. 

3943 

PARAM: .UBtocktng ...True if call is blocking St will not letura umU compieie. or false if 

non-blocking St reatms immediately as 'penling*. 

RETURN: Failure 
3930 su 



3935 



MuscSeOpeaed 
Memory AilocError 
Resource Alloc Error 
InocraalBrror 
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5960 



5965 



3970 



5975 



5980 



nitual RESULTCODE DerConncctl CALLPARAM& CaUPamn. 

STATION" ^pStttta. 

.UBloclonf » n » 0: 



USAGE: Conneci co remoie 
PARAM: _CaIlPmm 
jkSiaaon 
.IsBlacking 



RETURN: Fiiture 
Suecsss 



sunon or multipotni eoiurot unit. 

...Reference to i VCO call panmeter record. 

. ..Pit to remote sauon descnpcor to which connect is desired. 

...True if caU is blocking & witi not return unul complete, or fibe if 
non-blocking Sl returns immediately as "pending*. 



TmedOut 
MuttfieOpencd 



Memory AUocError 

RemrceAllocERDr 

ImenttlEmir 

InvaiidSaaon 

IflvaiidDaiaType 

LifieConnectFailed 

LineliBusy 



5985 



5990 



5995 



6000 



6005 



6010 



6015 



6020 



vtrtiMl RESULTCODE DerMumComiecK MXJLTICALLOP Op, 

CALLPAJUM& CaOPanm, 

STATION- ^pSutiOD ■ 0 

BOOL .liQuery - 0,' 
BOOL IiBlockmg » 1 > 



0; 



USAGE: Implement multipoim control opennon while 



connected to multipoinc control unit. 



PARAM: 



.Op 

.CallPinm 

j>SGUton 

_lsQuery 



RETURN: Failure 



TiraadOut 



NoiSttppofiBd 
Miiif BrOpc ne d 



Memory AllocError 

RemaxceAllocErrar 

ImcnttiEmir 

InnfalidSnttoo 

InwaiidDataType 

InvalidOpefSDon 

InvalidOpentioaNow 

CaUMussBeCamiectBd 

NoCaUForUaeAdd 



...Mutdpotnc conuoi openoon. 

...Reference to a VCO call panmeter record. 

...Ptr to staiun descriptor for selected openoon. 

...True if call U to query sub^siero for operanon capabUity. 

^^e if call u Mocking Al will not return umil complete, or false if 
noti-blocking A remms immediately as 'pending*. 
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60ZS 



6030 



6043 



6050 



6QS5 



6060 



virtual RESULTCODE DcvDisconBccK iAt ^aJLiae ■ 0, 

BOOL'tsBlockxnc » 1 ) • 0; 

/• 

USAGE: OUconncct one or more tines connected to remote uaoon or multipoim eomrol unii. 

PARAM: ^nLinc ...Number of line to disconnecc: null disconnects aU lines 

_IsBUJclang ...Tnie if call is blocking St will not return unol complete, or false if 

non-blocking St returns munediitely » 'pending' . 



RETURN: Failure 
Success 
Pending 
TiraedOut 
MttSiBeOpenrd 
InUsc 

*M0 MemoryAllocError 

Rc sou rccAJioc Error 
InicnttlEnor 
InvalidJLine 
CiUMustfieConneciBd 



virtual RESULTCODE DevAnswerC CAJULPARAM& CallPanm, 

tut "oUne > « 0; 

/• 

USAGE: Answer tncoming call from femoce sation. 

PARAM: .CaUPinm Reference lo a VCO call panmeter record. 

^nLine ...Number of line to disconnect: null disconnects all lines. 

RETURN: Faihm 



MustBeOpencd 
InUie 

MemoryAllocError 
ReaourceAUocEfTBr 
iBEentttEfxor 
[nwaltdDaaType 
InvalidLine 

^^^^ InvalidOpentnMiNow 

LineConnectFaited 



Tinual RESULTCODE DcvAboviO « 0; 
6070 /• 



USAGE: AboR entire eofmecdon. or conmcooo in progress, to remote saoon or multipoint comrel tiwit 
PARAM: 



6075 RETURNiFaihiTB 

Suooeu 
TimedOut 
MttuBeOpened 



«^ MemoryAUocError 

RaoarceAllocEm r 
tiuemalError 
CallMustfieConaecied 

•/ 

6085 
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6090 



6105 



6U0 



6U3 



6120 



nrtu.1 RESULTCODE OtirGtlCalUofol CALLPAIUM& _C.llP«n | - 0; 

USAGE: Get mfoniuuon for caU. or for ptnolly connecied call. Can be used white conneenon 
eiabltstimg lo ntonitor call pregicss. 

PARAM: .CallPmm ...Reference to a VCO call parameter recart. 



RETURN: Failure 
Success 

«95 TimodOui 

Musi&eOpened 
MuiiSeCiosed 
InUse 

Memory AltocEmr 

*™ ResoureeAUocError 

intEmalErrer 
InvalidOaaType 
UneNotCannecied 
LinelsBuvy 
DuconncctRequest 

•/ 



Tiitital RESULTCODE DewMediaCantroK MCO,TYPE Mc*Type, 

MCO 'setting 'Setttnf, 

DWORD 'PMn m 0, 

*OOL "isQuery - 0. 

/. BOOL .IsBloekinf - I ) « 0; 

USAGE: f«V*emem media art coiimrtseB^ 
uyea and MCI device dnveii. 

PARAM: (same as MedtaCoiiaol) 

RETURN: Fathue 



Pending 
TimedOut 



MustBeOpened 
6123 InUie 

Memory AlloeEmr 
ResourceAUocEmr 
hUEmaiCrrer 
TunerFaihtre 

6130 UndefuvdReult 

InvalidOaaType 
invalidOpcisiion 
InvalidOpenoooNow 
InvalidObiect 

6"5 InvalidSenui* 

IflvalidPaivn 
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viftuaJ RE51A.TCODE DevEinuCoiitroK EMliCONTKOLOP Op > « 0: 
6140 /• . - 

USAGE: Implemem cmuJuion comitit opennon for (his VCO. 

PAAAM: (ume u EmuComrol) 

RETURN: Fiihirc 
Success 



RequesxDenicd 

MustBeOpeaed 

McmofyAUocEiror 

RftSOurceAllocEnor 

LnxenttlEfTDr 

imratidOpeninm 

InvaiidOpennonNow 

6155 •/ 
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6lfi0 



6165 



6170 



6175 



6180 



6ias 



6190 



6195 



6200 



6205 



6210 



6215 



6220 



nnual RESULTCODE DevXmtOaU( BYTE* j,Bttf» 

tat .oBytci m 1. 
KMCO hMco » 0, 
BOOL .IsQucrr m o, 
BOOL .IsBlocldaf « i ) » O; 

USAGE: Traasmu d.u buffer co remo.e «.non. for . specific data object. 



PAJtAM: j^Buf 
.nSym 



.UQtttiy 
.IsBlocking 

RHTURN; Fulure 
Success 
TtmetfOut 
NoiSupponBd 
MusiBeOpeoed 
InUse 

MnnoryAJIocEiTDr 

Re*oureeAllocETOr 

IntemtlEnor 

lavaiidOataType 

invatidObjccs 

InvaltdPmm 

CaUMustBeConnected 



virtial RESUX.TCODE DevRcvDaU< BYTE* 

HMCO 
BOOL 
BOOL 



.Pir TO buffer conuining data. 
..Number of bytes to transmtt. 

.H«a«e to data object «, use for dau transfer: null mdiea.cs defauK. 
.Tme if call is 10 query sub-^nem for opeianon capability. 

noISLil^*i' * ~* ^OW. or false ,f 

non-Wocking 4e returns immeduiciy as -pewiuig ■ . ' ""^ " 



J»Bttf. 
.aBjrtcs - 1 
_hMco m 0, 

^IsBlocking » 1 ) « O; 



• — * f — 

USAGE: Po„ «^ « ^„ ^ .^^ ^ ^ 

PARAM- nRi.r 



PARAM: jiBuT 

.hMco 

.li(^iefy 

.UBlocking 

RETURN: Failure 
Succcu 
TunadOut 
NoiSupponed 
MttstBoOpeaed 
InUse 

Memory AilocEnor 

ReamReAllocEmr 

ImenaiError 

ImralidDaoType 

InvalidObjeet 

InvalidParam 

CailMiutBeCanneeted 



..-?0' to buffer cofuaining daa. 
...Number of bytes us cnnsrau. 

-.Handle to data object a use for data innsferrtuia ind«atcs deJault. 
...Tixie if caU is (o query sub-sysiem for operaaon capabdity. 

na^J^^^^ ^'"^^ * ""^'t^. or false if 

nofi-blockjng Sl renims uiunediasly as 'peiKling-. 
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6235 



6240 



6243 



6250 



6255 



6260 



62&S 
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Tirtual RESULTCODE Dev5etModcs( BASCODE* ^Meddist. 

iai oModcs • 1 ); 

/• 

USAGE: Actempi to set H.221 device modes for csil in pragress. 

PARAM: j>ModcLitt ...Pir to list (tmy ) of H.221 mode consano m set. 

_nh4ades ..Number of modes in tin. 

RETURN :FiUure 
Success 
TunedOut 
RequcstOtnied 
MustBeOpvfBd 
MefROfyAUocErrar 
Resource AJ tocEno r 
InsemaiErfor 
InvttlidDaiftTypc 
InvmUdMode 
InvalidPinm 
CallMustBeConaected 

•/ 

vimial RESULTCODE DevScndCapK BASCOX^* j>CapUst, 

ittt aCafs « 1 ) ■ 0; 

/• 

USAGE: Trurnnit the specified capability set to the remote xtaiion. 

PARAM: (same IS SendCaps) 

RETURN: Failure 
Success 
TunedCXu 
RrqimifVniPrt 
MusiBeOpetKd 
Memory AllocEiTDr 
Re»tnceAUocErTor 
IncenaiEnsr 
InvalidX^aaTvpe 
bnraltdCapabiltty 
InvalidParam 

•/ 
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virtual cobsi char* DevGttModcLabcK BASCODE _Mod« ) » 0; 
USAGE: Get text Ubel for spectfled H.221 mode. 
PARAM: .Mode ,„HJ2l mode eoiuant. 

RETURN: Pit to coiisom ehancter nnng if argumem valid, else null 

jirtuai conn char* DevGctCapLabcl( BASCODE Cap } m Q- 
USAGE: G« text Ubel for specified H.221 capibilicy. 
PARAM: ,Cap .. jj jjl capabUity conmm. 

RETURNiPtrujcoiuamsmogifargomem viiid.eisemj« 

vtrtnai MCOPARAM& DeirG«tMco< KMCO hMco ) - 0; 
6290 ^^^^ "^^"^ reference to sadc buffer conaming copy of media Ctrl object panmeter block 

PARAM: .hMco -.Handle to media ciri object. 

RETURN: Reference to copy of media Ctrl object parameter block for specified media Ctrl object 

S295 

nrtual HMCO DevGdMcoHandlcf cowl char* jiMeoLabcl ) - 0; 

USAGE: Reaim handle to media cart object specified by la label 
««» PARAM: j>McoUbel -Ptr » label «o medu ctri object label. 

REnjRN: Handle to media «rt object specified by the label. eUe null if no such media ctrl object fo««i. 

^ *tottsal HMCO DevGeiMcoHaudicf MCO_TWE .McoType ) « 0; 

USAGE: Re&im handle to media ctrt object specified by iu type. 
PARAM: .McoType ...Media ctrt object type. 

RErURN:Handle lo medU ctrt object specified by the type, die null if no such meda ctrl object found. 



6310 



6315 ««Sl^TCODEI>e*SetDefaiiUMco(MCO.TirPE McoType, 

coonchar^ IpMcoLabel ) - 0; 



6320 



63Z3 



6330 



6335 



USAGE: Set the VCO's default medu ctrt object for the specified object type. 
PARAM: _McoType ...Type of media cal object to which the default wUl be sei. 

jjMcoLabcl .Ptr to label for niedia ctrt object lo set as default. 



RETURN: Failuf* 

SuCBClS 

RortrinrtafU 

NmSupported 

MustBeOpened 



InUsc 

InaexnalEmr 
InvalidDataType 
InvalidObject 
InvalidSeoing 
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6340 



6373 



6380 



Ttrtual RE5ULTC0DE DcvSctDcfaullMcoi MCO_TYPE McoTypt, 

HMCO ~bMco>-Ot 

USAGE: Set ihe VCO's defauU medii Ctrl object for the ipccified object type. 

PARAM: ^McoTjrpe - - Type of medj» cirl object to which defauli medu ciri object will be set. 

,hMco ...Handle of media Ctrl object to set as default. 



63*5 RETURN: Failure 



NoiSupponed 
MustfieOpened 
6350 Disabled 

tnUse 

IntsmalBmr 

InvalidOataType 

InvalidObjeet 

6355 invaitdSening 



nnual RESULTCODE DcTSclTimcouiC DWORD Msec } • 0; 

USAGE: Set connea mneiMit for network imcifaee unit. 

PARAM: _Msec ...Tuneeui value ui millisecanls. 

RETURN: Failure 
ti>36S SuEceu 

TimedOut 
Rc^ucstDcnicd 
MustBcOpcned 
Memory AllocErTDT 
6370 RBSoufceAltocEnor 

ImenalEnor 
TimerFaihire 
lAvalidDataType 
InvalidPanm 



rimul RESULTCODE DeTVertFyBaiidwtdlh( BASCODE AudleMode, 

BASCODE ~DauModc/ttO; 

/• 

USAGE: Verify dot connection has sufficieni bandwidth for spectfied audioslaB mode combmanon. 
with ccspcet to dw cumm video mode <if appltcabtc). 



PARAM: ,AiidioMode ..J1J21 audio mode. 

6383 _DattMode ...H.221 data mode. 

RETURN: TimedOut 
Capable 



6390 MttStBeOpened 



Memory AllocError 
Resource AiiocError 
IncBraaiErior 

6393 (nvaltdMode 

CaUMusiBeCooneciEd 
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6400 



6405 



6410 



6415 



6420 



6423 



6430 



6435 



6440 



rintaX RESULTCODE DevIOControK lOCOimtOLOP Op 

DWORD 'Paiml - 0, 

DWORD ~Panai2 « 0, 

BOOL lUQmry « 0. 

BOOL IsBlocktiig - i > - 0; 



USAGE: 



PARAM: 



Imptemem inpui/oucpui device control openuon by mtkmg calls to device comni 
T^X:^T^S^r:'''V'''^ ccmponenr^ member fJSc^r^v^^^ 
Z^^Tr ^"PPon for specttliied. impleinenunoiKlependem 

SZS^ wet»-rcpfe«n«al m the sondart VCO dev«e comn,! m^n^TT^^ 

" « " m^sm » build .SL^^^ 

iinpui/output device comrol opentmn requesed. 

.If required, provides parameter nficeasary to fully specify request. 

.If required, provides paruiecer necessary to ftUiy specify request. 

-Tntc if call is to query nib-syscem for operation capability. 

Troc if call is blocking will not return uncU compiete. or false if 
notvblocking Sl returns immediitely as 'penltngV 



.Op 

.Pacaml 
_Pmm2 
^IsQuery 
,lsBIoeking 



RETURN: Fatluie 
Success 



Pfwding 

TiraedOut 

RequesiOenied 

MunBeOpened 

XnUse 

MtmoryAUocErrar 

ResotticeAlloc£rror 

luenalEnor 

TunerFaihire 

UrdsfmedResuli 

InvaUdDaaType 

invatidOpefanoQ 

InvalidOperaiionNow 

InvalidPanm 

...Othen according to unplememanon rtquutmems 
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BIT-RATE ALLOCATION SIGNAL HEADER FILE 



644J 



6450 



SAMPLE HEADER FILE 
for 

H^i bit-rate; allocation signals 

'jstd to iadiouc 
DEVICE MODES AND CAFABfLITIES 



6435 



6460 



_ . ABSIRACT 

Thtt iQurce nuxhile conouu header m/omauon Uui wUI provide a device •mdependem epnismoon of bii-nie illocaoon sinol 
comnunds (BAS codes! used to indicate device modes and ca)»biltdes accofding to the H.32Q (speciftcaUy HJ2l\ 
Recommendaoon. These lisu are imended for Uhutachre purposes, and are incomplete. An implrmenation of a VMCS would need 
10 defme a complete list, and then preserve the eaact numencat tdcnnty of diese consana for all implemenaiums .^^.^^fj for 
interopermtodify within die same operating environmem. vimialiaation rtmnnet in die VL (of VCO impiemenanonsi mun nnUie 
these deviceMndependem versions of H.221 modes and capabilities mco die actual BAS codes formats specuied bv die 
feeommeodaoon for line transmtssion. ^ 

(SOURCE FILE: BASCODES.m 



6465 



This module 
Che standard C 



PROGRAMMING NOTES 
only O lotirce ctnU and snueatred commenu usmg dte * // ' 
notadon using "/••/•). 



noaaoo to denote comments (in addidon 



to 



BIT-RATE ALLOCATION SIGNALS TO INDICATE DEVICE 
6470 CAPABILTnES (DEVICE MODE CAFABfLmES) 



6473 



6485 



6490 



6493 



// TRANSFER RATE CAPABILmES 
BASCODE CapTnnsferRala64 
BASCODE CapTnnsferRateJsM 
BASCODE CapTr«iisferRata3a64 
BASCODE CapTnaiferRato4i64 
BASCODE CapTnBifcrRalc5a64 
BASCODE CapTnasferRal«6s64 
BASCODE CapTnasferRauSM 
BASCODE CapTnssferRaU2x3B4 
BASCODE CapTnasferRaie3s384 
BASCODE CapTnBsferRste4x3S4 
BASCODE CapTniisferRate5K3S4 
BASCODE CapTrwnferRaUt536 
BASCODE CapTmaferRaumO 
BASCODE CapTffuifcrRaUUS 
BASCODE CapTfUifirRatem 
BASCODE CapTnasfcrfUuaSd 
BASCODE CapTraMfcrRatteSU 
BASCrODE CapTnaifcrRjite7«S 
BASCODE CapTffw»fcrRatAl252 
BASCODE CapTransferRBtei472 
BASCODE CapRcAiiGi 
BASCODE Cap 



'OaHOOOOOOl 
t Oi800Q00Q2i 
0x10000003 
> 0x80000004; 



I 0x80000006: 
• 0x 80000007; 
t 0x80000008; 
0x80000009^ 
I 0x8000000a; 
I Ox80(X3000b; 



> OiBOOOOOIOi 

> 0x80000020; 



■ 0x80000030; 



» 0x80000040: 



* Ox80000QS0; 



I 0x80000060: 
> 0x80000070; 



6500 



6303 



//AUDIO CAPABOJIIES 
BASCODE CapAudioALJiw 
BASCODE CapAttdloUUir 
BASCODE CapAudiaGTZS 64 
BASCODE CapAiidlDG722'48 
BASCODE rapAwiUoCTas" 
BASCODE CapAudloISO 

/ATIDEO CAPABILrnES 
BASCODE CapVtdeoQCIFl 
BASCODE CapVidcoQCXFZ 



I 0x80000080* 
' 0x80000090: 
I OxSOIXXXldO: 
> OxSOOQOQWh 
' Oi800000c0; 
. o« 



M OxSOOOOOcO; 
* 0x800000(0; 
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6S10 



6513 



6520 



6525 



6530 



6533 



6340 



6345 



6550 



6355 



6560 



6565 



6570 



BASCOOE 
BASeODE 
BASCOOE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 



capvidcooan 

C4pVldtoQCIF4 

CapVMcoan 

CapVidceCm 

CapVidcoCm 

CapVldcoCIF4 

Cap Video Improved 

CopVldMlSO 

CapVidtoComponti 




//IMAGE CAPABaXOES 
BASCODE CopSunlttPlclunLawSpccdDaU 
BASCODE CapSuBtUPIctimHIchSpeedDau 
BASCODE CapSiOttUPkliiraSpaUilModc 
BASCODE CapSiiBtonctiircPracmmMode 
BASCODE CapSantttnctonArithmttteModc 
BASCODE CapSiiBtttPtctiirtH261 
BASCODE CapGnmpJFax 
BASCODE CapGroitp4Faa 

//LOW SPEED DATA CAPABUJTIES 
BASCOOE CapUwSpcadOata Variable 
BASCODE CapLowSpeedOstaSOO 
BASCODE CapLowSpeadDataiaoo 
BASCODE Cap 
BASCODE Cap 
BASCODE CapLawSp 

BASCODE CapUwSp 

BASCODE CapLowSpewU)atoA4400 
BASCODE CapLo«SpaadD«Ul6K 
BASCODE CapLowSpaedI>ate24K 
BASCODE CapLowSpecdDatalZK 
BASCODE CapLowSpaadDato40K 
BASCODE OpUwSpccdDatoaK 
BASCODE CapLowSpccdDatsSOC 
BASCODE CapLowSpeedDala62K 
BASCODE CapLowSpiedDala64K 

BASCODE Capill«|iSpe«lDatal2IX 
BASCOOE CapHlchSpeedDauinK 

BASCODE C. p Mt,^ip — tfiw^tc^ 

BASCODE rapmih-iiMniniiatrmf 

BASCODE CapHifhSpaedOaftaSSdK 
BASCODE CapUI(hSpeadDBlaSt2K 
BASCODE CapHlchSpecdDslaTttK 
BASCOOE ga|>Hi|**jg ptartn,tjt |y7 f{; 
BASCOOE CapHighSpctdPrtatS36K 
BASCOOE CapHigliSpe^DoU 

//APPLICATION CAPABOJTIES 
BASCODE CapEooypttoo 
BASCODE CapGrepUoCunor 
BASCODE CapVUOLowSpccdData 
BASCODE rapVnanith'ipfrriniH 



« 0x80000100; 
" OaSOOOQZOO: 
• OxAO00O30O; 
« OkBOOOCMOO: 

- 0x60000500; 

- 0x80000600; 
"0x80000700; 
"OxSOOOO&OO: 
« 0x80000900: 



*• Ox80000a00; 
-OxSOOOOtaOO: 
-Ox8QOOOeOO: 
«Ox8O00Gd0O; 
-OxSOOOQoOO; 
« 0x80000100; 
-0x80001000; 
* 0x80002000; 



* 0x80003000; 
> 0x80004000; 

* 0x80005000; 
■O» 8000600 0: 

* 0x80007000; 
• 0x80008000; 



•0x80009000; 
"0x80001000; 
- QxlOOObOOO: 



'OxBOOOcOOO; 
'OxaOOOdOOO; 
»OK8000eOOO: 
•OxSOOOfDOO; 
'OxBOOlOOOO; 
< 0x 80 020000; 
•Ox80Q3000oi 



•0x80040000; 
> 0x80030000; 



-0x80070000; 
■0x80080000; 
■ 0x80090000; 
>0x800a0000: 
>Qx800b000O; 
*0x800e0000; 
" Ox8O0dD0OO; 



"OxSOOeOOOO; 



»Ox800fOOOO; 
- 0x80100000; 
" 0x80200000; 
-0x80300000; 



//MULTIPOINT CONTROL CAPABIUnES 
BASCODE CapSctCoDlFociis 
BASCODE CapQtteryCaalFocus 
BASCODE Cap&tCanfOudr 
BASCODE CapQuiryCoiifChalr 
BASCODE t^^r^'li tSfMtteii 
BASCODE CapAcBOToSCatloD 
BASCODE CapBroadattAodlo 
BASCODE CapBroadcaaVUco 
BASCODE CapBroadcastOata 



(VCO PROPRIETAAY) 
• OxSO^XXXX); 



•0x80400001 
-Ox804000QZ; 
-0x80400003 
-0x80400004 
-0x80400005 
-0x80400006; 
-0x80400007 
-0x80400008 
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6575 



6580 



BASCX)DE 
BA5CODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 
BASCODE 



C«pG«tNumSuUom 

CapGtSUfinnlift 

CapGciSUttoaCapi 

CapGctStatloiiAudfo 

CapGctSutioaVldBa 

CapGctSUUooDsU 

CapCetStotionldttnttty 



* 0x80400009; 



• OiaOtOOOOc: 
I Oi8O4O0O0il: 
> OxSO4O000e; 

* Oji80400QOf ; 



6585 



Btr-RATE ALLOCATION SIGNALS TO SET DEVICE MODES 
(DEVICE MODE COMMANDS) 



// TRANSFER RATE MODES 
BASCODE ModeTnaslcrRata64 

6590 BASCODE ModcTraBsfcrRaU2K64 
BASCODE ModcTrmasferRate3s64 
BASCODE Mod«TmttrerRate4i^ 
BASCODE Mod«TnBiferRat*5x64 
BASCODE MedeTnttBfcrRaic<s64 

6595 BASCODE ModeTmBfcrRsta3B4 
BASCODE ModtTnmf«rRaiA2x3M 
BASCODE Mod«TnasftrRaU3i3S4 
BASCODE ModeTnB9ftrRata4x38 
BASCODE ModtTnmftrRaUSx384 

6600 BASCODE Mod«TnnslcrRjitelS36 
BASCODE Mod«TnBiftrRBU19Z0 
BASCODE ModcTruilcriUlaUa 
BASCODE ModiTnaafcrfUlelSl 
BASCODE MMtnnM(mrB^U2S6 

6605 BASCODE ModtTninfcritattSU 
BASCODE ModtTnnslttRau768 
BASCODE ModtT^smlcrRBUll52 
BASCODE MotUTmufcrRatcUTI 

6610 /; AUDIO MODES 

BASCODE ModtAudloOfT I 
BASCODE MotftAudtoOrr 2 
BASCODE ModcAudiaALsw 1 
BASCODE ModttAuctiAALBw'l 

6615 BASCODE ModcAutUoALAw 3 
BASCODE ModftAudioULftw'l 
BASCODE ModcAiidloULaw~2 
BASCODE ModftAudlalA^«~3 
BASCODE ModcAaiU(»G722 1 

6630 BASCODE ModftAudiaGTS 2 
BASCODE ModeAiidloG722'3 
BASCODE ModtAodMOK 
BASCODE Mod«AMdio«K 
BASCODE ModcAudtoMK 

66Z5 BASCODE ModftAudtoaK 
BASCODE ModeA«idlo64K 
BASCODE ModsAodtoUBK 
BASCODE ModcAodlotRK 
BASCODE ModcABdlaZS6K 

6630 BASCODE ModtAudlaSMK 

// VIDEO MODES 
BASCODE Modt VIdcaOfr 
BASCODE Mod«VidceH26t 

6635 BASCODE MadcVidMlmpimd 
BASCODE ModaVldeolSO 
BASCODE Mod«VldMCampasttc 
BASCODE ModcVMeoCIF 
BASCODE Mod«VldMQCIF 

6640 BASCODE ModtVldco4C]F 

BASCODE Mod«VidcoClF340 



• 0x10000001 
' OntOOOOOQZ 

> 0x10000003 

> 0x10000004; 

> 0x10000005 

■ 0x10000006: 

> 0x10000007: 

• 0x10000008: 

■ 0x10000009; 

■ OxlOOOOOOi: 
'OxlOOOOOOb; 

• OxiOOOOOOc: 
" OxlOOOOQOd: 
" OxlOOOOOOe; 
" OxlOOOOOOf: 

• 0x10000010; 

> 0x10000020: 

■ 0x10000030; 
» 0x10000040: 

• OxlOOOOOSO: 



I QjiOOOOOOtP; 
I 0x00000003^ 



m 0x00000005 
a 0x00000006; 
n 0x00000007; 
B 0x00000008; 



M OxOQOOOOOb; 
« QxOOOOOOOc; 



■ OxOOOOOOOd 



* OxOOOOOOOe: 



* OfOOOOOOOf: 
" 0x00000010; 
m ObOooooo^O' 



I 0x00000040; 
I 0x00000050; 



» 0 x20 000 00 1 
■ Ot2fl0OQ00i; 



M Ot\ 20000003 ; 



* 0x20000005 
m n*7ffKW006' 
« 0x20000007; 
" 0x20000008; 

• 0 x 20000009; 
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BASCODE ModeVUfloFmc 
BASCODE ModtVldMltaltatt 
BA5C00E ModaVidcoFaftUpcUU 
6643 BASCODE ModtVUcoOocOa 
BASCODE ModtVldaoDocOfT 
BASCODE ModeVideoSpUtOD 
BASCODE Mod«Vtdco5plUOfr 

6650 y/IMAGE MODES 

BASCODE ModUSOSuutilPlcxurcLowSptcdData 
BASCODE ModOSOSoBtilPicturcHichSpMdOau 
BASCODE ModcUwSpMdDaUFax 

6655 BASCODE ModA^^Low^M^M 
BASCODE ModsJFEGHiihSpefidDau 

//LOW SWEio DATA MODES 
BASCODE ModtLMrSpwdDalaOtr 

6660 BASCODE Mod^xiwSpMdDalaSOO 
BASCODE ModtLswSptcdDaUUOO 
BASCODE ModtL«wSpMdData4IOO 
BASCODE ModtLow5pctdDaU6400 
BASCODE MadeLairSpwrtPrtaaOOO 

6665 BASCODE ModeLawSpcedDaU9600 
BASCODE ModcLowSpwdDaUl4400 
BASCODE ModtU»SpMdDaU16K 
BASCODE MadiLttirSpMdDMaMK 
BASCODE MAdtUwSpeMlDmCUZK 

6670 BASCODE MadtL«wSpMdDmte40K 
BASCODE ModeLewSpOTdDateax 
BASCODE ModtLMr5|indDaUS6K 
BASCODE ModdLa«5pMdDaiai2K 
BASCODE ModtLowSpctdDataMK 

6675 BASCODE ModtLawSpwdOBtaVutebto 

// HIGH SPEED DATA MODES 
BASCODE ModtKlghSpctdDataOir 
BASCODE ModtKiihSpMdOat«64K 
66B0 BASCODE MadclII|bSpMdDBU228K 
BASCODE ModtHUfhSpttdDatalffK 
BASTODE ModcHlghSpMdDvtalSCK 

6685 BASCODE M^SIIp^^H^S^^^^ 
BASCODE ModcHt|hSpctdDato7tfBK 
BASCODE ModciUchSpMdDBUilSZK 
BASCODE Modttti(hSpccdDitmlS36K 
BASCODE ModtBlfhSpMdO«UVariiblt 

6690 

// APPUCATTON MODES 

BASCODE ModcNnttnl 

BASCODE ModtEocryiictoBOn 

BASCODE MotfeEBCffTptlaBOfr 
6695 BASCODE ModsAndteLoopback 

BASCODE ModeVidtoLooptock 

BASCODE ModtRMctOa 

BASCODE ModtRcmietOir 

BASCODE ModtOtftUlLoepteck 
6700 BASCODE ModtLoepbickOfr 

BASCODE ModeComposttctfBOa 

BASCODE ModK:ompente6BOrr 

BASCODE ModcCurmOnLowSpecdDua 

BASCODE ModtFaxOoLowSpccdDau 
6705 BASCODE MedtFttEOaHlchSpccdDmU 

BASCODE ModeVt20LawS|M«dDsU 

BASCODE ModtVUOHiihSpccdDMB 



■ Ox2000000a: 
r Ox20OQ00(tt»; 

> Os2000000e; 
I Ox200000Gd; 
• OjOOOOOOOe: 
'0i2000000f: 

> 0x20000010; 



■ 0x20000020; 
"0x20000030: 
-0x 200000 40: 

■ 0x2 0000050: 
- 0x20000060: 

■ 0x20000070; 



'0x30000001 
■ 0x30000001 



"0x30000003; 
« 0x30000004: 
-0x30000005; 
-0x30000006; 
-0x3 000000 7; 
- 0x 30000008: 



'0x30000009: 
> 0x3000000x1 
■ Ox3000000b' 
I te3000QOQb' 
•OK300000dd: 
'0x3000000e; 
I OxSQOOOOOf; 
• 0x30000010: 
'0x30000020; 



'0x 300000 30: 

• 0x 30000040: 

> 0x30000050: 
■0x 30000060 : 

■ 0x 30000070; 

> 0x 30000080: 
'0x 300000 90: 

> 0x300000x0: 
'OxSOOOOObO: 

* Ox300000bO; 
' Ox30000QdO: 

■ 0x300000e0: 



* 0x20000060; 

- 0x20000070: 
-0x20000080: 
-0x20000090: 

- 0x200000x0: 

- Ox200000bO: 
-Ox200000cO; 
« Ox200QOOdO: 

- Ox200000eO: 
« 0x200000(0; 
m 0x20000100: 

- 0x20000200; 
-0x2000030o! 

- 0X20000400; 
-0x20000500; 
-Ox»00600; 
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6710 



6715 



6720 



6725 



6730 



6735 



6740 



6745 



6750 



6755 



6760 



6765 



6770 



PHYSICAL DEVICE INTERFACE HEADER FILE 

PHYSICAL DEVICE INTERF A CE HEADER FILE 
for 

VJRTUAUZED MVLTIMEDU CONNECTION SYSTEMS 
ABSTRACT 

Thii source moduJe comuns header infomucioii used pnmanly by the «rver componems in any Vimuitized MuUwudia Common 
Syttem (VMCSl unplemenaaon. If the ipecial keyword symbol ' VCO BUILD* ii dcfiwd pnor to inclusion of this file h 
indicate, to the eem|»ler thai a VCO ii being buUu and dte dus 'VL* be defined in fWL If this symbol is not defined it 
indicates itiai a VCO eltem appticaoon is being buUi. and only the header files needed m access members of class VDl szvl us pure 
virual device eoniral ovemde member functtons w ctau 'PDI*. need be considered during the software build process la dus my 
both the server (VCO> and cliem componems of the VMCS derive symbolic defuunons from the same source code bise. but no 
vendor-specific (device -dependent) code is at any nme visible lo die device-indepcndem cJiem appiicaiions. 

(SOURCE FILE: PDiM 

raoCRAMMING NOTES 

1. This module ctMuains onJy C^ + tottrce code and stnicntred eommems using dw ' // • noooon to denote comments (in sddidon 
10 the sundard C commem notaoon using * /* */ *). 

2. Symbols defined in the VDI St^twm Control /merfaee are shown m boldface type belmr. 

f include < OS.H > // include opennng system ai^ user imeiftce API 

fmctude < BASCODES.H > // IiKliide btt-rUB aUoesaon stgnil inlicuiofis 

^include < MCLH > Indude Medu ConmU Intertae device eonarel coiisanis and nucis 

^mctiide <VDLH> // lachrfe defininon for d»e VDI and aU less demed i 

OECljUlA-nON FOR CLASS VL 
-«-•■---•----••■••••/ 

class VL: public VDI ( 
pretBued: 

VUeonn char* _lniFile): 

vicmal *VLO; 

vtrual conn char* GctCLsasNameO { reoim "VL"; ); 
lifdcf ,VCO_BUILD 

— £i— Vendor-^ifie special purpose members needed to implemem more^derived PDI 

tnemben are defined here. These ftmcotms mas provide all services ncccssafy n 
format data and conzroi devices in a way consistent with those necessary to best impiemenr 
die overrides to die pure vtmaal device cotnol members in the VDI 

•/ 

#eadif 

): 

DECLARATION FOR CLASS PDI 
class PDI: puhlic VL ( 



// PDI DATA STRUCTURES 
dar* pLabd; 
char* pVcrsion: 
DEVCAPS 



XREF 
XREF 



oCaps; 

CapsfMaxCapsJ: 
Modes(MasModesl; 



//Pffo VCO Ubeti 
// Pir tt VCO version straw 
// Local device eapabtlides iisdng 
// Number of entries in 'Modes to Caps* xmf list 
// Number of emnes in 'Caps to Modes* iref list 
// *Caps to Modes' sref liu 
// "Modes u Caps' sref list 
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6775 



6780 



6785 



6790 



679S 



6800 



6809 



6810 



6815 



6820 



6823 



conn im 

const DEVICE 

ini 

im 

tm 

im 

im 

conu cftar* 
MCO BINDING 
HMCO* 
HMCO 



Devices: 

DcvfMuOevkes); 



nAudioObj: 

nVidcoObi: 

nlratfeOfaj: 

nDaaObj; 

pMeduUbclQ: 

pMeduBinding: 



hMoofMaxMcoType]; 
PDUconn chir* .IniFiIe): 
vifwal 'PDin: 



// Number of encapsulated devices 

// Eocapsulaied device ^**»irr 

it Number of media ctri objeco currendy avadable 

// Number of audio objects currcmJy availabie 

// Number of motion-video objects 

// Number of objects 

ff Number of dau objects 

// Pit to amy of piri to media ctri object labels 

// Pit to linked list of currem media ctrt ob|eu bindings 

Ptr to linked list of all available media cirl obieca 
// Defauk media ctr) object hamltes 



viraialconncbar*GetClassNameO ( reum •PDI"; ); 
RESULTCODE I>c«Cia(c< BOOUs 



RESULTCODE OtvAanrrr( CALlJPAIIAM*&Jnt ): 

RESULTCODE DcvAbonO; 

RESULTCODE DcvCklCalUafoi CALLPARAM& ); 

RESULTCODE ^M^dLOMi MCO.TYFEJWCO.SErnNC,DWORD,BOOL.BOOL ); 
RESULTCODE DcvEauiCoMral( EMIKTONTROLOP )j 

2^™? S!!?*^ ^ HMCO.BOOL,BOOL ); 

RESULTCODE DevRevOatK BYIE« Jtit,HMCO,BOOL,B0OL ); 

RESULTCODE 0«vSetModB< BASCODE*JiU )• 
RBSULTCODE DevSendCapsi BASCODE*. tnt \\ 



6835 



* DcvGcCModaLAbcir BASCODE ); 
cottA char* DevGdCapLabcK BASCODE ); 

MCOPARAM& DevG<tMeo( HMCO ); 
HMCO DevGttMeoUaBdte< cosai dhar* ); 
HMCO DevGelMcoUaBdIei MCO.TWE ); 

R^ULTCODE DevSeiOeUultMcof MCO TYPE^tm dW )• 
RESULTCODE DtrSclDelndtMcoC MCO~TYPE,HMCO ); 

RESULTCODE OevSetCoiiflK CONFrGPARAM& )• 
RESULTCODE OevGtiCoaflf( CONHCPARAMA ); 

RESULTCODE DevSctTimeouK DWORD ); 

RESULTCODE DevVcriryEaBdwIdtht BASCODE.BASCODE ); 

RESULTCODE OtvlOCooiroW IOCONTOOLOP,DWORD,DWORD.BOOL.BOOL ); 

// CALLBACK MEMBERS ACCESSED BY PROTCOL STACK AND MAC LAYER 

vMd Ux pascal NeiworkEvemf DWORD EvemCode. DWORD ^Parwn ). 

void far pascal Device£venK MCIHEAOER* j)MctHeader )\ 
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GENERAL VMCS HEADER FILE 

6840 « 

GENERAL HEADER FILE 
for 

VIR7VAUZEX> MUL77MEDU CONNECTtON SYSTEMS 

«W5 ABSTRACT 

This source module conaim header infonnation used by boch eliem and server compooems in any VimiaUitd Muitimg^ 
Coa/uetton System (VMCS) tmptemettaoon. In this way. bodi the server <VCO) aid diem componems of the VMCS derive 
symbolic defmuioia from the same source code base. Thu class serves as a capsione m die VCO class smic&ue: so as co pccsem 
every VCO cUeiu widj eaacdy die same member ftmcuons accessible from die same class cype. The addidao of unpteraemaoon* 
6850 specific members m diis clsis can proceed widwut effecdng VCO ifueroperabiliiy or siancUrd VMCS documeiusaoiL 

(SOmCEFlLE: VCO.H) 



PROGRAMMING NOTES 

6835 This module conams only 1 sottrce eodt and stnicurcd eommeius using the ' // * notaoon id denoce commems (in addidon co 
die sandard C commem noauon using ' /* V 

#uBhide <PDt.H> // Inehide defimwm for die PDI ai»i all less derived classes 

6860 



DECLARATION FOR CLASS VCO 

6865 class VCO: public PDI ( 
fwMlc: 

VCO(cattst char* InxFile); 

6870 

viratal 'VCOO: 

vtmial const char* GetCUssName() ( reum *VCO*; }; 

6875 private; 

/* Impleffleftouion-specific m erabera go here, tnchiding members to support : 
..,Oyftamic link library imptemeaotion 
...Access restncQon for VCO Qiexns 
...Safeguards agamsi re-emrancy and oiulD-instannabon 

6880 •/ 

}; 
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SAMPLE VCO CLIENT APPLICATION 



SAMPLE 
VIRTUAL CONNECTION OajECT 
CUENT APPLICATION 
Ibr 

ftagQ VIKTVAUZED MVLTIMEDIA CONNBCnON SYSTEMS 

— ABSTRACT 



(SOURCE FILE: VCOCUEf/r,CFP) 



, PROGRAMMING NOTES 

» ^s^' c'*^2o«:o; ^Z*? *c . . • no««.n „ .eno« co^enu ( U. 

6905 2. DeCMU r«la»d » opetmong lyiicm API s. u>l the ipecifics of a« tt«r imerf^e. tave been omioed for cUnry . 

i -'T?- Mr«3Si« m shown in boUbce type below . 
6910 <vcO.H> ''i-H«iesu«*^VCOSofrwe„Con«.in«rt^^ 



NONBLOCK 0 «t C.1U to -non-blockii^- mode (inimedutt 



OMBptrenUy . m onler » nooly themihw « evcm h« oken plice ttx hu mnered die siini. 



«««ftne NOTinCAT[ON,RECEIVER_MEMBER(_CUs», .Member ) \ 

«20 #definc EVENTPROC Noafier##_Cli«#Jf_Mcinbeft EVENT W, 

DWORB ~Paiiml. 

DWORD "Pmm2. 

STATION* j»S«aon. 

6925 '.CUtt*pNRO;\ HWOTIFIER .hNonfter){\ 

^ 1^ ( pNRO 7 pNRO.> ^Membeti .Id. JHnxmX, .Pmm2. jiSanon. .hNodfier ) : 0 ):A.. 



#define NOTmCATON.PROCf _CU«. _Member ) Nonfier##_CIu$#f .Member 
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6935 /* VCO Con/ierenctng Object Clm used by ciiem apptkuion to esoblish luionuDC medu Ctrl loopbtck 

cannecoon id remote nation. Logs iJt relevent connecQon and media control trace mfbnnaiwn id a fiie. Also, 
all mce in/onnaiion cmanaong from the VCO itself, iclaimg to the openiions of the VCO. are displayed (in 
reai-time) on dm console display. 

•/ 

6940 clau ConfQbfca \ 
public: 

BOOL IsAcdve: // True if die currera session u acove 

694S 

// Coosaicctor to establish session wtdi remote station (inittaie call, then set loopback) 
ConlDbjee((VCO& _Vco, char- .pTiaceFile): 

// Dcsmictor ends session widi remote saltan (hangup) 
6930 -ConfOtyectt); 



6980 



VCOSt Vco: // Refeivnce u> default VCO for session 

cbar* pTiaceFile; // Ptr to fUespcc for session trace file 

IP4 aiinKll hNotifyNodficr: // Handle far event notirxcaDon signil 

HNOnFIER hDisplayNodfier: // Handle for console message display sigiai 

6960 // Notifier handling procedure for coiuiectton and VCO events oansmiixed to this client clau object 

DWORD NodfyFrac( EVENT Id. 

DWORD 'Panml. 

DWORD ~Panm2. 

gTA TIOW j>Sauioa. 
696S HNOrmER _hNoDfier); 

// Notifier hanrihng procedure to display die VCO text stream mnsnBued to this diem elasi object 
DWORD OispUyProcfEVEKT U. 

DWORD ~Panml. 
6970 DWORD 

gT AHON* 

HNOTXF1ER hNoiifier ): 

): 

6775 /* Create 'thwUa' for all die VCO event batidling procedures used to direct tnggcr aotiftcations (anl text 
meaaages) to meinueii in the 'ConfObjcct* notiftcauon receiver ob|eci (NRO). 

•/ 

N0TmCAT10N^R£CEIVER.MEMBER( ConfObject. NodfyProc); 
NOTinCATION*R£CEEVER_MEMBER( ConfOh^ect. DisplayPrae): 



ConfObiecu:ConiObreet(VCO& .Vco. char* j>TrueFde) ( 



/" DecerminB if consoruetad VCO sippoRB device modes necessary co a confeme 
wten audio, video* and binary mfonnaiioa will be coneuRcndy shared. 

6985 •/ 

laAcdve - 0: 

Vco • ^Vco: 

pTiaceFUe - jp'^nccBle: 

hNoiifyNaiifier " 0: 

6990 hDiqilayNoiifier » 0: 

BOOL CanDoAi^ " 0: 

BOOL CaoDoVideo - 0: 

BOOL CsiiDoDaa » 0: 

DWORD EvemMask - NcwRcvModc | NewXiBtMod* ( NewVeoStaU ( NcwCaOSUte: 

6995 DgVCAPSA LocalCsps « Vco. G«tD«vtecPsras(). Cape. LmI: 
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for < tnt i « 0: I < LocilCayw nCapa; t-*-t- ) | 

if ( I nril Cip» .C«rtit - - Cap VideoQCIFI ) // Captblc of video mode *» 

TOW CanDoVideo • I: 

if (LocalCaps.Cap(i) • - CapAudioAUw) // Capable of audio mode ? 

CanDoAudio — I: 

if (LoaaCaps.Cap(i] - - CapHighSpeedData384K) // Capable of data mode ' 
CaoDoDaa ■■ I; 

7005 ) 

If media cul modes supponed. open VCp for usage: 
sesip nodftcaoons and dien inidaiize devices 



7010 



7OZ0 



7025 



7030 



7099 



7040 



7045 



7055 



7060 



if (CanDoAudio SlSl CaoDoVideo CanDoData) ( 



Vco.NcwNoUfiert hNottfyNodfier. 

NOTlHCATTON_PROaConfObjeet. NotiiyPfoc). 
diis, 

7015 EmMask ); 

Vco.£aabliNoUiIer( bDispUyNodTier ); 

Vco.NewNoUneri h Ptipiay Nodfier. 

NOrnnCATON_PROC(ConlObicct. DispUyPnx:), 
diis« 

NtwTcrnOmput >: 



// Acdvate die sending of VCO messages lo die dispUy console 
Vco.ACttchTcffnBTaNetlflv( hDisptayNodfler ): 
Vco.EaablcNottllec< hDispUyNodfler ); 

'^^^^ ■ // NUrk diis session u cuRenUy acdve 

^ Vco.Optn( NONBLOCK): Waliie and aciivate encapsulated lub^siem 

// Otfierwise indieaie failure lo suppon opennons. and ciil 
^ else pranfC 'Seiecied VCO incapable of eoncumm media ctrt session.\n* ): 

ConfObieeL*:-Conl065«c<) { 

// tf cunemty in call, hang it up and output message to tiace file 
if(Veo,IsC«llO){ 

Vco.ToTcratiinK 'Hangmg up call in pngnsai prior u close. Vn' ) 
^ Veo.lUBCttp(): 

Vco.aoM(): // Sba&lown the encapsuUted sub-system (wait undl camptete) 



//I 

Veo JklcttNottfIcK hNoiiiyNoiifier ): 
VecDalcteNoUflert hDispUyNodfler ): 

7050 ^ primfCVCO baa been cloaed.\n"); 



DWORD ConfQbicct::DisplayPfoc( EVENT Id. 

DWORD "Pmrni. 

DWORD ~Panni2. 

STATION* jtSttiion. 

HMOrnnER _hNo(ite)( 

pfintfC • %s\n- .(char*>.Panm2 ): // Display die text mesuge on die console (std ouipui) 
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DWORI>Con(Obiecs::Naitf^PfOC( EVENT td. 

DWORD ~Pinml. 

DWORD 'PansO, 

TOdS ST ATION* jiSiMtea. 

HNOTXFIER ^hNodfier ) ( 



7070 



7075 



// Pnicftss all events chai irigger nodfteaaon 
vwicch ( _Xd ) { 

caie NcwRcvModt: il Log new mode set by remote sabon 

VccToTenainaK 'Mode Set by RemoteSadon ( %% W, 

Veo.G«lModeLabcl((BASCODE) Panml) ); 

bmk; 



ease NcwXmiMode: // Log new mode set by local saoen 

Vco.ToTanBiiu]( 'Mode Set by Local Siadon ( fts 1\n*. 

Vco.C«tModcLAbeKrBASCODE) PuamO ): 

break: 

7080 

case N«wVcoScaU: V/ Handle new VCD sate 

fwiKh ( (im)_Panml ) { 

case VcoOpea: // Cat! default remote station when opened 

Vco.ToTcmiianU 'Succeasftil VCD open: Calling default remote stadon.\n' ); 
7083 Vco.Caa( 0. 0. NONBLOCK); 



7I0S 



7110 



7113 



case VcoOaia: // Log new VCO close sats. then marie session inacave 

VcoToTetniBiH 'VCO has been dos^.Vn* ); 
7090 IiAofve • 0: 



t VcoFaflad: // Log VCO error state, then mart session inacitvc 



7093 VGoToTcmdnaU 'VCO Enor Coi^iuon (%s]\n*. 

Vco.GctVcQSiataLabcl((tm).Puunn: 

IsAciive « 0: 



7100 



) 

case NcwCaOStaU: // Haitf e new VCO call state 

swittfa ( (inU^Paraml) ( 

case CafiDteooBccscd: // Log diacotmcct of call: end output m oace file: mark session 

Vco.ToTcrminnir 'DtxconnecKd from Remote Saxum.Vn" ): 
VeoJktncbTcraiFraatf TcnaODevFUi ): 
XaAoive 0; 



X CaBCatucdteg: // Begin cnee file output: trice start of call connection cvetn 

Vco JUtachTcnttToFQe( pTcaceFite) : 
Veo.ToTcrmmnir 'Connecting To Remote 5cstiofi.\nT J; 



eaae CaSCeaneocd: // Upon conneciion. trace formaoed session utformatum to Tife 

Vco.ToTciaiBatf 'Connected bo Remote Stanon: Lisiing coaneeoon daia.\n* ): 
VcoXJACalU^rvBO: 
Vco.UttMCOiO: 
7120 VeoXtstConaecUeBCnpsO: 

// Loop audio, video, and daa input signaia back to remote sanon 
Vco.ToTcfmiBnlf *ScmBg up media cirl loopback...\o* ); 
VeoJllctfaCenimj( Audioln. AaacbTo. AudioOitt ): 
7123 VcoJ#edwOM0oK Vidcoin. AnachTo. VidooOui ): 

' VcD.ilfffdi£aCaAiTO/f Daialn. AnuhTo. DaiaOuc ); 
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7130 



713S J 

bmk: 

b«k: 

} 

7140 feoanO: 

) 



// Set local audio and video <iiue and display) m noniior inpuc sigoab frem the nraoie scaiion 
Vro MtdinCoaovU Audtoln. AfluhTo, AudioDii >; 
VeoMtOttCaaavH Videoln, AtadiTo. VideoOit »: 



7145 *f 



VCOCliemAppikMonwcaUremoiBhoa. l^pil^ 
wfUAs tnce of diagnonic tcxuon infonnatum to tacking tton to nal'^inie. 



)( 

// CoRsoia a selected VCO 
7150 MyVco Vco( -CAVCCINr ): 

// CoQsmict the conlefencing object 

MyCUentApp ConfDIqeetf My Vco, •C:\VCO.LOG' ); 

7IS5 // Bloek white dw conneciiviiy session is tdnre 

wtiite ( MyCUtti8App.lsAcdve ); 
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What: is claimed is: 

1. A multimedia connectivity program residing in 
computer readable memory, said connectivity program when 
executed on a computer providing to an application 

5 progrEun multimedia connectivity services through a real- 
time multimedia device control subsystem including 
components selected from among a plurality of multimedia 
devices and a plurality of real-time multimedia protocol 
stacks, said program comprising: 

10 a single binary object encapsulating a virtual 

device interface and a device control interface, said 
virtual device interface including a plurality of virtual 
methods that represent logical operations available to 
the application program for controlling said multimedia 

15 device control subsystem, said plurality of virtual 

functions being completely independent of the components 
within the device control subsystem, said device control 
interface mapping said plurality of virtual functions to 
physical control methods which control the components of 

20 the multimedia control subsystem. 

2. The multimedia connectivity program of claim 1 
wherein said device control interface comprises a 
plurality of media control objects which represent 
audiovisual and binary data streams associated with the 

25 components of the plxirality of devices and/ or real-time 
multimedia protocol stacks. 

3. The multimedia connectivity program of claim 1 
wherein the virtual device interface is configured to 
present a logical representation of the multimedia 

30 connectivity services provided by the connectivity 
program. 
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4. The multimedia connectivity program of claim 1 
wherein said device control interface comprises a 
virtualization layer and a physical device interface 
layer, said virtualization layer located between said 
virtual device interface and said physical device 
interface, said physical device interface directly 
interfacing to the device control subsystem to provide a 
physical implementation of services requested by the 
application through the virtual device interface, said 
virtualization layer residing between the virtual device 
interface and the physical device interface layer and 
configured to translate and map device control mechanisms 
employed by the underlying multimedia control sub-system 
to representations required by the virtual methods of the 
virtual device interface. 

5. The multimedia connectivity program of claim 2 
wherein the plurality of media control objects provides 
the multimedia connectivity control program with a pool 
of media device signal resources. 

6. The multimedia connectivity program of claim 5 
wherein each of said plurality of media control objects 
is classified as at least one of type of the group 
consisting of an audio type, a video type, an image type, 
and a binary data type. 

7. The multimedia connectivity program of claim 6 
wherein each of said plurality of media control objects 
represents a signal from the group consisting of a signal 
from a remote station, a signal to a remote station, a 
signal from a local output device, and a signal to a 
local output device. 
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8* The multimedia connectivity program of claim 7 
wherein operations performed on the pliirality of media 
control objects by the physical device layer under 
control of the virtual device interface implements a 
5 logical software switching mechanism connecting incoming 
signal paths to outgoing signal paths. 

9 * The multimedia connectivity program of claim 1 
wherein the virtual device interface implements a 
plurality of public member functions, said virtual 
10 functions being a subset of those public member ftmctions 
and wherein said plurality of public member functions 
represents all of the public member functions in the 
single binary object that are accessible by the 
application program. 

15 10. A computer programmed to provide to an 

application program multimedia connectivity services 
through a real-time multimedia device control subsystem, 
the multimedia device control subsystem including 
components selected from among a plixrality of multimedia 

20 devices and a plurality of real-time multimedia protocol 
stacks, said programmed computer comprising: 

a virtual device interface and a device control 
interface, both of which are encapsulated in a single 
binary object, said virtual device interface including a 

25 plurality of virtual methods that represent logical 
operations available to the application program for 
controlling said multimedia device control siibsystem, 
said plurality of virtual fxmctions being completely 
independent of the components within the device control 

30 subsystem, said device control interface mapping said 
plurality of virtual functions to physical control 
methods which control the components of the multimedia 
contr o 1 subsystem • 
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11. A computer implemented method of providing 
multimedia connectivity services through a real-time 
multimedia device control subsystem, the multimedia 
device- control subsystem including components selected 
from among a plurality of multimedia devices and a 
pliirality of real-time multimedia protocol stacks, said 
method comprising: 

defining and supporting by computer implemented 
steps a virtual device interface; and 

defining and supporting by computer implemented 
steps a device control interface, wherein both of said 
virtual device interface and said device control 
interface are encapsulated in a single binary object, 
said virtual device interface including a plurality of 
virtual methods that represent logical operations 
available to the application program for controlling said 
multimedia device control siibsystem, said plurality of 
virtual fiinctions being completely independent of the 
components within the device control subsystem, said 
device control interface mapping said plurality of 
virtual functions to physical control methods which 
control the components of the multimedia control 
subsystem. 
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FIG. 3a 



FIG. 3b 



FIG. 3 



VIRTUAL DEVICE INTERFACE (VDt) 



SOFTWARE CONTROL INTERFACE 



EVENT NOTIFICATION 
CONTROL MEMBERS 



CONFIGURATION/ 
SYSTEM SETUP 
CONTROL MEMBERS 



TERMINAL SERVICES 
CONTROL MEMBERS 



NETWORK SERVICES 
CONTROL MEMBERS 



NOTIFICATION CONTROLLER 



NOTIFICATION 
TRIGGERING 
MECHANISM 



NOTIFIER 
OBJECT 
LIST MANAGER 



TERMINAL STREAM CONTROLLER 



TERMINAL 
STREAM 
INPUT/OUTPUT 

DEVICE 
CONTROLLER 



TEXT 
COMMAND 
RECODER/ 
DECODER 



LINKED NOTIFIER OBJECT LIST 
(NOTIFIER OBJECT DATABASE) 



LINKED TERMINAL STREAM 
INPUT/OUTPUT DEVICE LIST 



VI RTUALIZATION LAYER (VL) 



: EVENT CONTROLLER ^ 


LINGUISTIC CONTROLLER 3 


: EVENT PROCESSOR K 


EVENT 
LABELLER 
MECHANISM 


X 
X 

>< 

X 
X 
X 
X 
X 


OBJECT > 
COMPONENT < 
LABELLING I 
MECHANISM ' 


: PERIODIC EVENT DISPATCHER R 


: INFINITE FIFO EVENT QUEUE K 


EVENT AND OBJECT STRING c 
LABEL DATABASE < 


CRITICAL SECTION HANDLER ^ 



PHYSICAL DEVICE INTERFACE (PDI) 

FIG 



3a 



SUBSTITUTE SHEET (RULE 26) 



wo 98/09213 PCT/US97/15018 

4/35 



S OFTWARE CONTROL INTERFACE, 

BINARY DATA^^ 
OBJECT EXCHANGE 
CONTROL MEMBERS 



MEDIA CONTROL/ 
, SIGNAL SWITCHING 
mNTROL MEMBERS 



SYSTEM INFORMATION! 

STORE/RETREIVE^ 
CONTROL MEMBERS 



PRDTOCCUOAT 
CasflROL MB/BBS 



DEVlCEffROTOCOL CONTROLLhR S (LOGICAL IMPEMENTAIONS Uh SCI OPERATIONS) 



OBJECT 
CONSTRUCTION 



CONFIGURATON/ 
SYSTEM 
SETUP 



NETWORK 
CALL 
STATE 



CAPABILTTY 
EXCHANGE 



MEDIA 
CONTROL 
OBJECT 
ACCESS 



OBJECT 
DESTRUCTION 



BINARY DATA 
OBJECT 
EXCHANGE 



SYSTEM 
INFORMATION 



SYSTEM 
RECEPTION 



PROTOCOL 

MODE 
NEGOTIATION 



DEVICE/PROTOCOL CONTROLLERS (VIRTUALIZED 

IMP! FMENTATIONS OF CORRESPONDINGT^DI COMPONENTS) 



SW 
COMPONENT 
LOAD/ 
INITIALIZES 
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INFORMATION 
ACCESS 



CALL 
EVENT 
MAPPING 



CAPABILITY 
MAPPING 



SW 
COMPONENTT 

UNLOAD/ 
SHUTDOWN 



DATA 
EXCHANGE 
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MAPPING 



SYSTEM 
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MAPPING 



SYSTEM 
EXCEPTION 
MAPPING 
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DRIVER 
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DEVICE 
CAPABILITY 
UST 



CONNECTIVITY 
PROTOCOL 
STACK 



CONNECTMTY 
PROTOCOL STACK/ 

MEDIA ACCESS 
CONTROL 



FIG. 3b 
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MODE 


DESCRIPTION 


DEBUG 


OUTPUT DEBUG INFORMATION IN MESSAGE BOX 


USER 


OUTPUT "USER" INFORMATION IN MESSAGE BOX 


TERM 


OUTPUT TEXT INFORMATION TO TERMINAL PORT 


NOTIFY 


REPORT EXCEPTION BY TRIGGERING SIGNAL 


ABORT 


ABORT CURRENT OPERATION AND DISABLE VCO 



EXCEPTION HANDLING MODALITIES 



FIG. 6A 



MODE 


DESCRIPTION 


DEVICE 


SEND DEVICE CONTROL MESSAGES TO TERMINAL 


NOTIFY 


SEND NOTIFICATION MESSAGES TO TERMINAL 


MEDIA 


SEND MEDIA CONTROL OBJECT MESSAGES TO TERMINAL 


CALL 


SEND CALL CONTOL MESSAGES TO TERMINAL 


LINE 


SEND LINE STATE MESSAGES TO TEMINAL 


PROTOCOL 


SEND PROTOCOL MESSAGE TO TERMINAL 



TRACE OUTPUT MODALITIES 

FIG. 6B 
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FIG. 7-1 



FIG. 7-2 



FIG. 7 



CLASS "VDI" (VIRTUAL DEVICE INTERFACE) j 



SOFTWARE 
COrsTTROL INTERFACE MEMBERS 



OPEN 

CLOSE 

CALL 

MULTICALL 

HANGUP 

SETCONFIG 

STATCCONRG 

REFRESHCONFIG 

SETUPAUDIODEVICES 

SETUPVIDEODB/ICES 

SETUPIMAGEDEVICES 



SETUPDATADEVICES 

MEDIACONTROL 

SETCONFPROFILE 

SENDMODES 

SENDCUPS 

VERlFYBANDWiDTH 

SETDEVICESTIMEOUT 

XFERBUFFER 

XFEROBJECT 
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DEVICE CONTROL MEMBERS 



DEVOPEN 

DEVCLOSE 

DEVCONNECT 

DEVMULTICONNECT 

DEVDISCONNECT 

DEVANSWER 

DEVABORT 

DEVGETCALLINFO 
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DEVRINGCONTROL 
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DEVREVDATA 
DEVSETMODES 
DEVSENDCAPS 
DEVGETMODELABEL 
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DEVSETCONFIG 
DEVGETCONFIG 
DEVSETTIMEOUT 
DEWERIFYBANDWIDTH 
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CLIENT 
CALLS 
TO 
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CLASS "PDI" 
(PHYSICAL DEVICE INTERFACE) 



PURE VIRTUAL 
DEVICE CONTROL OVERRIDES 



DEVOPEN 

devclose 
Hdevconnect 
devmulticonnect 
devdisconnect 
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devgetcallinfo 
devmediacontrol 



DEVREVDATA 

DEVSETMODES 

DEVSENDCLIPS 

DEVGETMODELABEL 
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DEVGETMCO 

DEVSETCONFIG 
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DEVSETTIMEOUT 
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DEVXFERDATA DEVIOCONTROL 



K/ / / / 



3 CLASS "VL" 
> (VIRTUALlZATIONk 



LAYER) 



TO FIG. 7-1 



CLASS VCO (VIRTUAL CONNECTION OBJECT) \ \ 

^ FIG. /-I 
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FROM X 
FIG. 7-2^ 



CLASS "MCO" 
(AUDIO FROM REMOTE) 



CLASS "MCa* 
(VIDEO FROM REMOTE) 



CLASS "MCQ' 
(IMAGE FROM REMOTE) 



■f 



CLASS "MCQ' 
(DATA FROM REMOTE) 




CLASS "MCQ' 
(AUDIO TO REMOTE) 



> 



CLASS "MCa" 
(VIDEO TO REMOTE) 



< 
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(IMAGE TO REMOTE) ^ 



CLASS "MCO" 



(DATA 



STANDARD 

OR 
VENDOR- 
SPECIFIC 
PROTOCOL 
STACK 
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> 



CLASS "MCO' 
(AUDIO FROM DEVICE) 



CLASS 'MCO' 
(AUDIO TO DEVICE) 




VENDOR- 
SPECIFIC 

MEDIA 
ACCESS 
CONTROL 



CLASS "MCO" 
(VIDEO FROM DEVICE) 



CLASS "MCO' 
(VIDEO TO DEVICE) 



VENDOR- 
SPECIFIC 

MEDIA 
ACCESS 
CONTROL 



CLASS "MCO" 
(IMAGE FROM DEVICE) 



CLASS "MCO' 
(IMAGE TO DEVICE) 



VENDOR- 
SPECIFIC 

MEDIA 
ACCESS 
CONTROL 
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CLASS "MCO' 
(DATA FROM DEVICE) 



CLASS "MCO' 
(DATA TO DEVICE) 



FIG. 7-2 
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, ENTER , 
'PROCEDURE' 

CAP] ^ 



FETCH MODE LABEL 
F=ROM ESJEMT LABELLBR 
fCALL GEmODELLABELl 



i 



DETERMirOE IF LOCAL SnwnON 
CAPABLE OF INPLTT IVODE 

rCALL ISSTATIONCAP 
FOR LOCAL CAPS USTINGI 




YES 



1 



DETERMINE IF REMOTE STATION 
IS CAPABLE OF INPLTT MODE 

[CALL ISSTATIONCAP 
FOR REMOTE CAPS UST1NG1 



CLEAR MODE SUPPORTED 
FLAG (CONNECTION 
INCAPABLE OF MODE) 




OLTTPUrTEXT MESSAGE 
'CONNECTION INCAPABLE 
OF MODE' fCALL TOTERMINAL1 



SET MODE 
FLAG (CONNE( 


SUPPORTED 
:TI0N CAPABLE 
/lODE) 




r 


OUTPUT TE 
"CONNECTION 
MODE' rCAU 


XT MESSAGE 
IS CAPABLE OF 
. TOTERMINALl 



f 

EXITH- 




FIG. 12 
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FIG. 14 




CALL CONTROL STATES 
[LINESTATES] 

"ENUMERATED LINE STATES;" 
LINEDISCONNECTED] 
LINEDIALED] 
LINEBUSY] 
LlNERINGl 
llNERINGBACK] 
iLINECONNECT] 

[CALLSTATES] 

"ENUMERATED CALL STATES; 
rCALLDISCONNECTED] 
[CALLCONNECTING] 
[CALLCONNECTED] 



HANDLE DISCONNECT SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXECLINEDISCONNECTED] 



HANDLE DIALED SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALLSTATES 
(CALL EXECLINEDIALED] 



HANDLE RING SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXECLINERING] 



HANDLE RINGBACK SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXECLINERINGBACK] 



HANDLE CONNECT SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALL STATES 
[CALL EXECLINECONNECT] 



HANDLE BUSY SEQUENCE 
FOR VARIOUS EXISTING CALL 
CALLSTATES 
[CALL EXECLINEBUSY) 



SUBSTITUTE SHEET (RULE 26) 



wo 98/09213 



PCT/US97/15018 



20/35 




SUBSTITUTE SHEET (RULE 26) 



wo 98/09213 



21/35 



PCTAJS97/15018 




SUBSTITUTE SHEET (RULE 26) 



4- 



WO 98/09213 



PCT/US97/15018 



22/35 





— ETT" 

Sen 

M 










=:lu 




1 ^ 










If 




SUBSTITUTE SHEET (RULE 26) 



wo 98/09213 



PCT/US97/15018 



23/35 




SUBSTITUTE SHEET (RULE 26) 



wo 98/09213 



PCTAJS97/15018 



24/35 



CO 
LU 

3 
$ 

CO 



CQLJJQlfeO 
LUCO UJOCD 














.UE 






P 

LU 




► 






C/D 





o 

u. 



LU UJ 
CD- CD ^ 



C/3 
tXl 



iili 



UJ 





SUBSTITUTE SHEET (RULE 26) 



wo 98/09213 



PCT/US97/15018 



25/35 



O 
CM 

CD 




50C2CD 




ID 

O ^ 



b<ujJ2o 






SUBSTITUTE SHEET (RULE 26) 



wo 98/09213 



PCT/US97/15018 



26/35 



ENTER 
PROCEDURE , 

[^/E0^Aco^^^ROLl 

^[QUERYMODg ^ 



VERIFY IF VCQ IS , 
FULLY OPERATIONAL 
(^1± ISVCOENABLED) 




VERIFY MEDIA ACCESS CONTROL 
DRIVERS ARE OPEN AND MED^^ 
DEVICES ARE AVAILABLE FOR USE 
(CALL GETDEVICEPARAM) 



SET FltnJRN VALUh 
TO INDICATE VCO 
DISABLED 




VERIFY "MCO" SETTING IS 
ACCESSIBLE AND THAT THE 
MEDIA DEVICE SUBSYSTEM 
SUPPORTS ITJSSyE MCp 
COMMAND TO PDUCALL 
DEVMEDIACONTROL 



SET RETURN VALUE TO 
INDICATE MEDIA DEVICES 
ARE UNAVAILABLE 




SET RETURN VALUE TO^ 
INDICATE MEDIA DEVICES 
INCAPABLE OF COMMAND 



0 



SET RETURN VALUE TO 
OE MEDIA DEVICES 



INDIC 
CAR 



ILE OF COMMAND 



FIG. 21 
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ENTER 
DESTRUCTOR 
[-VCO] 



CONSTRUCT TERMINAL 
EXCEPTION. AND ^ ^^^^ 
EVENT-DISPATCHING CLASSES 
\MTH SPECIHED PARAMETERS 



I 



INmAUZE SYSTEM INFO 
DATA STRUCTURES TO 
KNOWN STARTUP VALUES 



I 



RESTORE INTERNAL VCO 
CONFIG TO VALUES IN 

BACKING STORE 
[CALL REGRESHCONFIGl 



I 



SEND VCO SHUTDOWN 
TEXT INFORMATION TO 
TERMINAL OLTTPLn" 
(CALL TOTERMINAL) 



ATTACH TERMINAL OUTPmi 

AND INPUT TO DEFAULT 
INPLTT/OUTPLnr RLE/DEVICE 
(CALL ATTACHTERMINAL..) 



I 



START EVENT DISPATCHERV 



OUTPUT TEXT MESSAGES 
SHOWING DEVICE/SW 
VERSIONS & CONRGS 
FOR THIS VCO 
(CAU- TOTERMINAL) 



I 



I 



DETACH AND 
DELETE NOTIRERS 
ATTACHED TO 
VCODES/ICES 



CREATE NOTIRERS AND 
ATTACH EACH TO 
A VCO DEVICE 



I 



ENABLE VCO 
EMULATION MODE 
IF SPECIRED IN 
CONRGURATION 



I 



START EVENT 
DISPATCHER 



ENABLE VCO EMULATION 
MODE IF SPECIRED IN 
CONRGURATION 



FREE ALLOCATED 
BUFFERS AND 
OBJECTS 



(g) 



FIG. 24 
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ENTER 
PROCEDURE 
[OPEN! 

I 



IRE ) 



VERIFY IF VCO IS 
FUULY OPERATIONAL 
fC^isCcOENABLED) 



OUTPUT TEXT MESSAGE 
'PCI:OPEN(.J' 
(CALL TOTERMINAL) 




OPEN ALL ASSOCIATED 
VCO MEDIA/CONNECTION 
DEVICES (CALL DEV OPEN 



SET RETURN VALUE 
TO INDICATE VCO 
DISABLED 



INCREMENT VCO 
REFERENCE COUNT 
(UPDATE RELD IN 
DEVICEPARAM) 



INCREMENT VCO 
REFERENCE COUNT 
(UPDATE RELD IN 
DEVICEPARAM) 

— 



UPDATE VCO 
CONRG FROM 
BACKING STORE 
(CALL RESTORECONFIG) 



^'DEVICE OPEN 
^SUCCESSFUL^ 

? 

Tno 



SET RETURN VALUE TO 
THAT RETURNED BY 
CALL TO PCI 





RESET ALL CALL PARAMS 
TO DEFAULT UNCONNECTED 
VALUES rCALL RESETCALLl 








r 




RESTORE DEVICES TO DEFAULT 
UNCONNECTED MODES ^„ 
(CALL RESTOREDEFAULTMODEg 



I 




GOTPUT TEXT MESSAGE 
"NEW CUENT ADDED" 
(CALL TOTERMI NAL) 

i 



SET RETURN VALUE TO 
INDICATE VCO OPEN 
OPERATION SUCCESSFUL 



J 



FIG. 25 
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ENTER 
PROCEDURE 
[CLOSE] 



VERIFY IF VCO IS 
FULLY OPERATIONAL^ 
(CALL iSVCOENABLED) 



OUTPUT TEXT MESSAGE 
'PCI:CLOSEC...)" 
(CALLTOTERMINAL) 




RESTORE DEVICES TO 
DEFAULT UNCONNECTED 
MODEJCALL RESTORE- 
DEFAULTMODES) 



J 



SET RETURN VALUE 
TO INDICATE VCO 
DISABLED 



DECREMENT VCO 
REFERENCE COUNTT 
(UPDATE FIELD IN 
DEVICEPARAM^ 



J 



CLOSE ALL ASSOCIATED 
VCO MEDIA/CONNECTION 
DEVICES 
(CALL DEVCLOSE) 



DECREMENT VCO 
REFERENCE COUNT 
(UPDATE RELD IN 
DEVICEPARAM) 



SAVE CURRENT VCO 
CONRG TO BACKING 

STORE 
(CALL STORECONRG) 

T 




SET RETURN VALUE TO 
THAT RETURNED BY 



CALL 



OUTPUT TEXT MESSAGE 
•VCVO CONRG SAVED' 
(CALLTOTERMINAL) 



OUTPUT TEXT MESSAGE 
"CUENT REMOVED" 
(CALLTOTERMINAL) 




SET RETURN VALUE TO 
INDICATE VCO CLOSE 
OPERATION SUCCESSFUL 



OPCI 



FIG. 26 
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ENTER 
PROCEDURE 
[HANGUP] 



VERIFY FVCO IS " 
FULLY OPERATIOr^^ 
{CS± ISVCOENABLED) 



YE! 




SET RETURN VALUE TO 
INDICATE VCO DISABLED 



SET RETURN VALUE TO 
INDICATE VCO NOT OPEN 



SET RETURN VALUE TO 
INDICATE TVIAT CAU. 
MUST BE CONNECTED 



OUTPUT TEXT MESSAGE 
"HANGING UP CALL" 
fCALLTOTERMINAL) 



ISSUE CALL ABORT 
COMMAND TO PCI 
(CALLDEVABORT) 



SET RETURN VAUJE TO 
SiDICATE RESULT OF 
ABORT COMMAND 



FIG. 29 
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OPERATION 


DESCRIPTION 


SetConFocus 


Set confeFenoe focus to specified station 


QueryConfFocajs 


Determine identity of station currently in focus 


SetConfChair 


Set conference chairman 


QueryComfChair 


Determine identity of conference cliairmen 


AddStation 


Add station to conference 


RemoveStation 


Remove station from conference 


BroadcastAudio 


Enable or disable broadcasting of audio conference 


BroadcastS/ideo 


Enable or disable broadcasting of video corrferenoe 


BroadcastData 


Enable or disable broadcasting of data conference 


GetNumStations 


Get nurr^3^ of conferees 


GetStationUst 


Get list of conferees 


GetStationCaps 


Get capabilites of particular conferee 


GetStationAudio 


Get audio of particular conferee 


GetStationVideo 


Get video of particular conferee 


GetStationData 


Get data of particular conferee 


GetStationidentity 


Get numtiers and station label of particular conferee 



MULTIPOINT CONTROL OPERATIONS 

FIG. 30 
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